A reader wrote in to tell me we should update our articles about SVG <use> elements. The attribute we always use for them, xlink:href, is deprecated. Indeed, MDN says:
That’s pretty strong language, hence the reader’s warning. This is a bit surprising to me, as the SVG 2 thing got a little weird. It looks like it did become a Candidate Recommendation though.
So…
<!-- This is old -->
<svg>
<use xlink:href="#whatever" />
</svg>
<!-- This is new -->
<svg>
<use href="#whatever" />
</svg>I like it. But does it actually work? Lemme fork my little old demo and change all the references. In a quick run through of what I have easy access to:
| Chrome 67 | Firefox 61 | Safari 11 | Edge 17 | IE 11 | iOS 11 |
|---|---|---|---|---|---|
| ✅ | ✅ | 🙅♂️ | ✅ | ✅ | 🙅♂️ |
Better than I thought! But enough 🙅♂️ no-go’s there that up and switching everything seems far too dangerous, especially when xlink:href has support across the board.
Will browsers actually pull support? I’ll bet ya fifty bucks none of them ever do. There are tons of websites that use the attribute in the old format that will never update, and we know that browsers take breaking old sites very seriously (yay).
It feels like the same thing with, for example, :before and ::before. Yeah, ::before is the new and more correct syntax. But no browser will ever pull support for :before (I’ll bet ya another 50 bucks) because it just needlessly breaks sites. And because of that, it almost makes the most sense to keep using :before as you get the widest swath of support that way.
I probably won’t be updating older articles using <use xlink:href="" /> unless something bizarre happens and some browser actually does pull support.
Yeah, MDN’s “in the process of being dropped” boilerplate is a little ambitious.
Even when Safari/iOS finally add support for
hrefwithoutxlink, browsers are required by the current spec to maintain backwards compatibility support for thexlinkversion, and I wouldn’t expect that to change in a future spec, either.There’s no security reason to drop it, the change is all about making it nicer for authors. And there’s nothing nice to authors about breaking old websites!
There have been other changes in the SVG spec where features have been dropped completely, but only in cases where those features never gained universal support and/or much use.
xlink:hrefdoesn’t meet that test.So
xlink:hrefwill likely stay “deprecated” forever (not the recommended solution, but browsers must maintain support), never shifting over to “obsolete” (doesn’t work no more).Surprised by the support from IE11.
So, if I want to use just href, what should I do? Wait for Safari to get an update or maybe put both attributes?
I feel the latter makes little sense, though…
If you aren’t updating the articles, you’re part of the reason deprecated code never gets updated. And why browser developers get away with not prioritizing adding support for new standards. Browser developers hate when old sites break because of code support being pulled, but also hate when new sites break because their browser doesn’t support the new standards. Because in the latter case, that is a much bigger driver for users to switch browsers. If svgs start looking weird on iOS, Apple is going to add support right away before users switch to that other browser their friend uses tbat never has that problem.
Insightful post, btw.
I removed ‘xlink:href’ from my SVGs and switched to using just ‘href’, then found that iOS browsers (Chrome, Safari) would no longer handle the links. My workaround was simply to use both variants: is there any reason (aside from the inelegance of repetition) not to do this?
xlink:href may be deprecated, but dropping it from your code while there are still widely-used browsers that depend on it seems like a bad idea.
Don’t forget the namespace for xlink. Had this issue a while back and wrote about it https://kartikprabhu.com/articles/href-in-svg
There doesn’t seem to be any reason not to just use both attributes, right?
Using both attributes is even suggested in the SVG2 spec;
I tried writing both and it seems to work. So my policy will be:
– Keep the old code as it is. Probably will work forever and if, at some time in future, deprecation is effective and browsers drop support, it will be very old, and probably icons will be just one concern :-). And nobody will reclaim you those 50 bucks.
– In new code write both. It will work now and after deprecation. If you use macros, components, mixins… whatever, it will be trivial, otherwise just some more typing.
– When iOS and Safari supports it, drop the namespaced version.
You should be able to make the
href=""on SVG work with JavaScript. Years back, Eric Meyer was supportive of the idea, or came up with the idea, of allowinghref=""on more elements in the HTML5 spec. I was also supportive of this idea, but unfortunately, the idea was rejected and never made it into the HTML5 spec. I’m pretty sure Eric wrote a script to make the linking work for the purposes of a demonstration (see the second link). This, of course, could be used to enable the linking until browser support improves.https://meyerweb.com/eric/html-xhtml/html5-linking.html
Looking at browsers does not tell the full story. You need to consider support in editors and renderers for standalone SVGs.
In the wild, the vast majority of existing SVG files are authored with Inkscape or Adobe Illustrator. Both do not support
hrefwithoutxlink:, reading or writing.There are a lot of legitimate reasons to do server side rendering to a raster format. Chances are you will use ImageMagick, which in practice means the actual rendering is delegated either to librsvg or Inkscape. librsvg (a tool developed for rendering icons on the Gnome desktop, and by far the fastest renderer available) needs the namespace, also. Don’t even think about older tools like the Java Batik library.
(The other widespread application is SVG-to-PDF conversion, but I cannot comment on that.)
Leaving out the namespace might sound “modern”, but it will not produce reusable code for the forseable future. Keeping it is nothing more than a few extra bytes that won’t bother anyone.
Hi, if i am used ‘href’ than its not working on chrome, still xlink:href working in SVG. Not deprecated….
It’s still deprecated in the spec, but it’s up to browsers whether or not to continue supporting it. So, yeah, you’re correct that Xlink:href is not deprecated in Chrome. :)
A heads up — the latest Safari Technology Preview release (v63) added href support yesterday (August 15). See: https://webkit.org/blog/8403/release-notes-for-safari-technology-preview-63/