Preact: xlinkHref renders an 'href' attribute, not 'xlink:href' attribute

[everdimension]

Well, subject.
preact version: 6.4.0

[developit]

On what type of element?

[everdimension]

<use xlinkHref="#icon-name" />

...which is inside of an svg tag, of course

[developit]

Strange, I have demos of this working. Will check if there was a regression..

[everdimension]

Thanks!

[developit]

hmm - it definitely is still working:
https://jsfiddle.net/developit/0qgbw2sg/4/

Perhaps you're inserting the <use /> prior to the href target being available?

[developit]

Might also be worth checking a second browser (possible issue).

[everdimension]

Hm, you were right about inserting the <use /> tag before target was available.

But still. If I have static <use /> tags (inserted in raw html without javascript with xlink:href tags, then it works even though the targets are loaded later.

I'm not completely sure, but I believe the reason is that preact strips the xlink: part.

In your jsfiddle example if you inspect the rendered elements you'll see that the <use> tag only has an href attribute.

[developit]

That's actually just an oddity with how attributes work from JS vs from HTML. Preact uses .setAttributeNS(), which excludes the namespace (explanation here).

In that jsfiddle, if you grab the element in console and look at $0.attributes, you should see that the xlink attribute has the correct namespace.

CSS Tricks has an article that goes over some of these awkward bits, might be worth a read:
https://css-tricks.com/gotchas-on-getting-svg-into-production/#article-header-id-2

[developit]

@everdimension think we can close this out, at least in terms of being a preact issue? The oddity here is more about how inline SVG's work in HTML documents, not really about Preact itself.

[developit]

Closing for now but please feel free to discuss here on on gitter!

[rmales]

As far as I can see, when calling setAttributeNS the namespace prefix can 'optionally' be a part of the attribute (qualified) name. React uses the prefixed version, it might be worth doing the same if there is no downside?

[developit]

@rmales You mean just to avoid stripping it out?

[rmales]

@developit I was actually looking into bug report which I thought might be related to this, but I think that is more likely a Firefox issue.

It's probably not worth changing it, unless you want to match React or cover some non-browser rendering cases.

[developit]

@rmales I'm totally fine looking into this if adding the namespace to the name argument doesn't break anything. Maybe it'll even let us shrink the size! 👍