Hacker News Reader

Comment by mablopoule | Hacker News Reader

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

  <!-- Should be in all your pages -->
  <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>
      <!-- other icons here -->
    </defs>
  </svg>

  <!-- In some other template -->
  <button>
    <svg class="icon"><use xlink:href="#icon-circle"></use></svg>
    <span>foobar</span>
  </button>

  <!-- in your CSS -->
  .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)

View on HN

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

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.

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.

> 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.

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.

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 :/

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.

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.

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.

<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.

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.

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

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...

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

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.

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.

This approach prevents CSS styling though since SVG referenced this way has its independent DOM and is not part of the current page DOM.

Yes, in that sense it's more like CSS sprites, just a bit easier to use.

I use this approach all the time.

Reply on news.ycombinator.com