4 ms·

Apart from font-icon, a nice way to handle icons in a website is to leverage the underutilized <use> SVG element:  <svg

Apart from font-icon, a nice way to handle icons in a website is to leverage the underutilized <use> SVG element:  <svg style="display: none" aria-hidden="true"> <defs> <symbol id="icon-circle" viewBox="0 0 20 20"><circle fill="currentColor" cx="10" cy="10" r="10" /></symbol>  </defs> </svg>  <button> <svg class="icon"><use xlink:href="#icon-circle"></use></svg> <span>foobar</span> </button>  .icon { width: 1em; height: 1em; } This approach I feel has most of the advantages of inlined SVG (mostly context-dependent colors) while avoiding most of the clutter, and is not heavily reliant on a specific JS-based workflow (thought we do need to includes our <def> somewhere in all pages)

kragen 6y ago
I like <use> but for the WWW I'm reluctant to stray from the absolute most common SVG elements and forms of combining them; I've had too many cases where what works on one browser fails in another, or sort of works but far too slowly to be usable. It's a lot like HTML in the 1990s that way.
- mablopoule 6y ago
  Yeah, I've been saddened by the depreciation of SMIL for animation, for example. SVG can be rough around the edges sometime when it comes to cross-browser support of less-used features :/
  - chrismorgan 6y ago
    Google wanted to deprecate and remove SMIL, but public outcry was sufficient that they suspended those plans indefinitely, and I haven’t heard anything against it in the years since.
- deckard1 6y ago
  for what it's worth, my company was using this method and we were supporting, I think, ie10 at the time just fine. No issues that I know of. some advanced features of SVG, such as filters, are very much YMMV to this day. But for simple logos and icons there isn't much to worry about.
  - kragen 6y ago
    Yeah, I don't remember which things I've run into trouble with—it's just enough that I'm very cautious about using any SVG features outside the bare minimum.
- chrismorgan 6y ago
  <use> and <symbol> have been an integral part of SVG for yonks. I remember it working robustly even in Adobe SVG Viewer days (my Dad made extensive use of them in some software), and although some small details have changed concerning how interaction-based styles apply (:hover and the likes) it’s always been dependable.
- jimmont 6y ago
  https://developer.mozilla.org/docs/Web/SVG/Element/use#browser_compatibility https://developer.mozilla.org/docs/Web/SVG/Element/use#brows... shows nearly complete green across the board, frontend tech years are like dog-years; without more info I'd suggest leaping forward to <use> <svg>; in other words it's not like the 1990s anymore--every modern browser have continuous updates, robust native APIs that make the majority of contemporary legacy tech workflows prior to 2017-ish obsolete, and Google's bot processes JavaScript as a mobile client by-default as I recall. Browsers are more consistent and robust in their implementations than ever before, making contemporary solutions easier to implement and performant both for consumers and developers--providing they know of these and use them.
draw_down 6y ago
Be careful with those IDs. They are global to the document, and bad things happen when they clash.
skrebbel 6y ago
Oh wow, I did not know this one! And the browser compatibility seems top-notch [1], really nice, thanks! :-) https://developer.mozilla.org/en-US/docs/Web/SVG/Element/use#browser_compatibility https://developer.mozilla.org/en-US/docs/Web/SVG/Element/use...
voldemort1968 6y ago
Came here to recommend this approach. Lots of FE devs don't know about this. Nice overview here too http://tutorials.jenkov.com/svg/use-element.html http://tutorials.jenkov.com/svg/use-element.html
city41 6y ago
Is it possible to include the defs in perhaps a <link>, so they can be downloaded once and cached across all pages?
- ygra 6y ago
  You can reference elements from an external file just as well: <use xlink:href='icons.svg#foo'/> Theoretically the browser should only download that file once, just as with multiple img elements referencing the same image. I haven't seen that approach much in the wild, though.
  - city41 6y ago
    Good to know. This has me thinking it'd be cool to have a babel plugin or something that extracts out svgs like this. I currently have a website that heavily uses svgs and for the bulk of them I resorted to img elements because embedding the svg so many times increased the size of the html significantly. This use approach seems like it might be better.
  - lenkite 6y ago
    This approach prevents CSS styling though since SVG referenced this way has its independent DOM and is not part of the current page DOM.
    - ygra 6y ago
      Yes, in that sense it's more like CSS sprites, just a bit easier to use.
shubhamjain 6y ago
I have tried this, but adding symbols to the file becomes a giant PITA. Then, you also have to ensure that symbols are loaded on every page. I had some SVGs that were multiple kilobytes (logos and stuff), and this just increased the page weight. You can give my library, svg-loader, [1] a try. It's a single line of javascript that makes it really easy to load external SVGs as inline elements. The syntax is even shorter and you avoid all the problems of external SVGs. [1]: https://github.com/shubhamjain/svg-loader https://github.com/shubhamjain/svg-loader
- bhl 6y ago
  I'm not sure if this library is better. If you're making an XHR for each inline svg, then that's a lot of unnecessary network requests compared to a dynamically generated svg sprite-sheet at build time. The latter is definitely possible with a pre-defined sprite UI library like Material Design or Font Awesome mentioned in the blog post.
  - shubhamjain 6y ago
    With HTTP2, the cost of making a request is incredibly low and almost.not worth optimizing for non blocking resources. Unless, you're loading hundreds of icons, you shouldn't notice that much of a difference.
- zamalek 6y ago
  > I have tried this, but adding symbols to the file becomes a giant PITA. I use Affinity Designer for this. It exports artboards using a trivially detectable pattern, which can be easily turned into symbol elements in a compilation step. I made a feature request for an option to do this natively, but it never got any traction.
dvergeylen 6y ago
I use this approach all the time.

kragen 6y ago

I like <use> but for the WWW I'm reluctant to stray from the absolute most common SVG elements and forms of combining them; I've had too many cases where what works on one browser fails in another, or sort of works but far too slowly to be usable. It's a lot like HTML in the 1990s that way.

mablopoule 6y ago
Yeah, I've been saddened by the depreciation of SMIL for animation, for example. SVG can be rough around the edges sometime when it comes to cross-browser support of less-used features :/
- chrismorgan 6y ago
  Google wanted to deprecate and remove SMIL, but public outcry was sufficient that they suspended those plans indefinitely, and I haven’t heard anything against it in the years since.
deckard1 6y ago
for what it's worth, my company was using this method and we were supporting, I think, ie10 at the time just fine. No issues that I know of. some advanced features of SVG, such as filters, are very much YMMV to this day. But for simple logos and icons there isn't much to worry about.
- kragen 6y ago
  Yeah, I don't remember which things I've run into trouble with—it's just enough that I'm very cautious about using any SVG features outside the bare minimum.
chrismorgan 6y ago
<use> and <symbol> have been an integral part of SVG for yonks. I remember it working robustly even in Adobe SVG Viewer days (my Dad made extensive use of them in some software), and although some small details have changed concerning how interaction-based styles apply (:hover and the likes) it’s always been dependable.
jimmont 6y ago
https://developer.mozilla.org/docs/Web/SVG/Element/use#browser_compatibility https://developer.mozilla.org/docs/Web/SVG/Element/use#brows... shows nearly complete green across the board, frontend tech years are like dog-years; without more info I'd suggest leaping forward to <use> <svg>; in other words it's not like the 1990s anymore--every modern browser have continuous updates, robust native APIs that make the majority of contemporary legacy tech workflows prior to 2017-ish obsolete, and Google's bot processes JavaScript as a mobile client by-default as I recall. Browsers are more consistent and robust in their implementations than ever before, making contemporary solutions easier to implement and performant both for consumers and developers--providing they know of these and use them.

draw_down 6y ago

Be careful with those IDs. They are global to the document, and bad things happen when they clash.

skrebbel 6y ago

Oh wow, I did not know this one! And the browser compatibility seems top-notch [1], really nice, thanks! :-) https://developer.mozilla.org/en-US/docs/Web/SVG/Element/use#browser_compatibility https://developer.mozilla.org/en-US/docs/Web/SVG/Element/use...

voldemort1968 6y ago

Came here to recommend this approach. Lots of FE devs don't know about this. Nice overview here too http://tutorials.jenkov.com/svg/use-element.html http://tutorials.jenkov.com/svg/use-element.html

city41 6y ago

Is it possible to include the defs in perhaps a <link>, so they can be downloaded once and cached across all pages?

ygra 6y ago
You can reference elements from an external file just as well: <use xlink:href='icons.svg#foo'/> Theoretically the browser should only download that file once, just as with multiple img elements referencing the same image. I haven't seen that approach much in the wild, though.
- city41 6y ago
  Good to know. This has me thinking it'd be cool to have a babel plugin or something that extracts out svgs like this. I currently have a website that heavily uses svgs and for the bulk of them I resorted to img elements because embedding the svg so many times increased the size of the html significantly. This use approach seems like it might be better.
- lenkite 6y ago
  This approach prevents CSS styling though since SVG referenced this way has its independent DOM and is not part of the current page DOM.
  - ygra 6y ago
    Yes, in that sense it's more like CSS sprites, just a bit easier to use.

shubhamjain 6y ago

I have tried this, but adding symbols to the file becomes a giant PITA. Then, you also have to ensure that symbols are loaded on every page. I had some SVGs that were multiple kilobytes (logos and stuff), and this just increased the page weight. You can give my library, svg-loader, [1] a try. It's a single line of javascript that makes it really easy to load external SVGs as inline elements. The syntax is even shorter and you avoid all the problems of external SVGs. [1]: https://github.com/shubhamjain/svg-loader https://github.com/shubhamjain/svg-loader

bhl 6y ago
I'm not sure if this library is better. If you're making an XHR for each inline svg, then that's a lot of unnecessary network requests compared to a dynamically generated svg sprite-sheet at build time. The latter is definitely possible with a pre-defined sprite UI library like Material Design or Font Awesome mentioned in the blog post.
- shubhamjain 6y ago
  With HTTP2, the cost of making a request is incredibly low and almost.not worth optimizing for non blocking resources. Unless, you're loading hundreds of icons, you shouldn't notice that much of a difference.
zamalek 6y ago
> I have tried this, but adding symbols to the file becomes a giant PITA. I use Affinity Designer for this. It exports artboards using a trivially detectable pattern, which can be easily turned into symbol elements in a compilation step. I made a feature request for an option to do this natively, but it never got any traction.

dvergeylen 6y ago

I use this approach all the time.