If you're building an icon system for a site, you have some options. If you know the icons need to be raster images, then you'll likely be using CSS sprites. If the icons will be vector images (much more common these days), you have some options. Two of those options are using inline SVG and using icon fonts.
Let's compare.
Icons are Vector
There are big advantages to vector icons: resizable up and down without losing quality, extra sharp on retina displays, and small file size among them.
| Icon Font | Inline SVG |
|---|---|
| Browsers consider it text, so the icons are anti-aliased as such. Can lead to icons not being as sharp as you might expect. | Straight up vector |
In a recent personal example, while converting some icons from fonts to SVG on CodePen, some of the font icons were noticeably less sharp than the ones I converted over.
CSS Control
| Icon Font | Inline SVG |
|---|---|
You can control the size (via font-size), color, shadows, rotation, etc. via CSS.
|
You have all the same CSS control as with a font, but better, because you can 1) control individual parts of a multi-part icon and 2) use SVG-specific CSS like stroke properties. |
Positioning
| Icon Font | Inline SVG |
|---|---|
It can be frustrating to position a font icon. The icons are inserted via pseudo element, and it depends on line-height, vertical-align, letter-spacing, word-spacing, how the font glyph is designed (does it naturally have space around it? does it have kerning information?). Then the pseudo elements display type affects if those properties have an effect or not.
|
SVG just is the size that it is. |
Weird Failures
| Icon Font | Inline SVG |
|---|---|
|
An icon font might fail because 1) it's being loaded cross-domain without the proper CORS headers and Firefox doesn't like that 2) for any reason, the font file fails to load (network hiccup, server failure, etc) 3) There is some weird Chrome bug that dumps the @font-face and shows a fallback font instead 4) Surprising browser doesn't support @font-face. Font failures are pretty common for a variety of reasons. |
Inline SVG is right in the document. If the browser supports it, it displays it. |
Semantics
| Icon Font | Inline SVG |
|---|---|
To use responsibly, you're injecting the icon via a pseudo element on an (empty) <span>. Either bad or no semantics, depending on how you feel about that kind of thing.
|
Icons are little images. The semantics of <svg> says "I'm an image." Seems better to me.
|
Accessibility
| Icon Font | Inline SVG |
|---|---|
| You have to be quite careful with icon fonts to make sure you do it in an accessible way. You should basically do everything in this article. You're always fighting to make sure that the icon itself isn't read (but something else is) and that hard-to-detect fail states are handled. |
I'm no expert, but research suggests using the proper combination of elements and attributes (<title>, <desc>, and aria-labelledby) you can convey good information across the browser specturm. Plus no weird fail states.
|
Ease of Use
| Icon Font | Inline SVG |
|---|---|
| Using a pre-created icon font was never particularly responsible (too many unused icons). Creating your own icon font was never overly comfortable. I think the best were Pictos Server (limited to Pictos icons) and IcoMoon (free login to save projects). Fontello has an API I didn't see it used to make a good build tool. | The inline SVG system is easier because you can do it all by hand if needed. Or use a tool like IcoMoon (exports either way). Or use a build tool. |
Browser Support
| Icon Font | Inline SVG |
|---|---|
| Very deep. Even IE 6. | Decent, but problems are IE 8- and Android 2.3-. Fallbacks doable but not wonderful. |
Winner
It all comes down to browser support. If you can go IE 9+ / Android 3+, inline SVG is better at pretty much everything than icon fonts. If you need the deeper browser support, I feel like an inline SVG fallback would be too big of a pain to be worth it (maintaining a PNG copy, inserting an additional element to display PNG version, hiding SVG element... it's weighty).
Man, I’d love to go nuts with SVG, but IE8 support is still a must for me. It’s a damn shame.
If you still need a quick tool for custom social icons. http://perfecticons.com/ is a great resource.
Hope to have an inline SVG version eventually.
@ivan – your link isn’t working
@Aaron Hall – Odd. Seems to be getting traffic. Catch me at @jivinivan with more details.
Hi,
Interesting! I’ll give a try to that IcoMoon feature that I hadn’t test yet.
Johan
Interesting article. I think http://fontawesome.io/ is excellent product to use (surprised it’s not mentioned in there). It’s very easy to use and can use any classes to apply to.
What about performance? An icon font is a great way to reduce the number of HTTP requests by combining a huge amount of icons into a single file. You can even embed the font file as base 64 in your main css file.
Also, about “semantics”: I don’t consider an icon a “little image” as in that is not part of the content. An icon is part of the decoration, a visual hint or indication.
Inline SVG is embedded in the document so there are zero additional http requests. There is a hit though since it wont cache the Inline SVG for use with other documents.
Regarding performance/HTTP requests, can’t you have an external SVG document with all of the icon definitions that gets referenced on the page via
usetags? This would provide the benefits of caching, with minimal HTTP requests.Not disagreeing with your conclusion in general, but I think that fonts could win on semantics in at least some cases. I’m thinking mostly of situations where the icon accompanies the word it’s intended to convey, like: “[hamburger] Menu.”
In the case of SVG: there is semantically an image there, which to me implies that the image conveys more information than is included in the text. Visually it does, by providing a means of quick recognition without needing to read the actual word; semantically, though, it simply repeats.
In the case of the icon font: there’s a span there, which is by convention semantically neutral (in other words, it doesn’t give the appearance of conveying additional information).
It’s a minor quibble, and probably more a matter of perspective than anything. And, obviously, this doesn’t apply to situations where the icon stands alone or actually does convey additional information (like a sparkline or something).
I am eagerly waiting for the 2020′s when Microsoft will drop support for Windows 7, and along with it Internet Explorer 8.
And Chris, thanks for the article! Pushed me to learn SVG now. :D
Was hoping you had registered a short code for [cagematch]
Use SVG with the awesome Grunticon from filament group http://filamentgroup.com/lab/grunticon for DIY command line version or http://www.grumpicon.com/ for web app version.
It does all the fallback PNG and css for you
I use and love grunticon (or at least the grumpicon webapp), but I feel like that implementation might be missing some of the benefits Chris mentions, because the SVGs are inserted as a
background-image.Take
:hover/:activestates, for example. With inline SVG you have the CSS control ofstroke,fill, etc with the ability toanimateortransition, but with grunticon, you’re forced to swap out the icon with another just to change the color. Each of those states adds to the weight of the CSS include, since you have multiple copies of the same icon.I’d love to see a grunticon/grumpicon style tool for compiling a folder of SVGs into one document with all of the icons as definitions, accessible via the
usetag. Just like grunticon, the tool could also create a PNGbackground-image(base64 encoded) fallback for IE8 and Android 2.3-, then a external PNGbackground-imagefallback for IE7-.Markup would probably be something like:
(Forgive me if that doesn’t display correctly. The preview of it kept not displaying the code at all)
In your CSS, you would size the
spanand make thesvgfit it withwidth: 100%; height: 100%(a viewbox attribute might be needed, I’m not sure). The fallback CSS would target thespanto give it the PNGbackground-imagewithbackground-size: containAnyone interested in taking this on? :D
Glad you point that out about IE8- support. My inbox is full of newsletters spouting the latest insights on SVG but I cannot even begin to play with them because IE8 fallbacks are a pain. It’s not quite like doing without text-shadow or border-radius on IE8. SVG’s (and an icon system) would solve so many performance issues for us – my graphics guy just doesn’t understand what I go through to try to compress his bloated files.
My big hope is that with XP support gone, businesses and schools (from where the vast majority of our traffic comes) will soon be upgrading to Win7|8 and skip on up to IE10+. Then a whole new world of possibilities emerges. (Oh my goodness, I need to start learning more about …)
*<canvas>
I’m sold! No more icon fonts.
Thank you for such a thorough analysis.
Another feature of SVG that I like is the true vector advantage of being able to resize the same image code. Here: http://maxw3st.us/svgshare/share_reveal.html the icons at the top of the page and those under the “share” panel are the same svg code resized. This can be handy if you want to resize images for RWD without getting into multiple copies of the image. Comments in the CSS code explain how I did it, just “view source”.
how do you use svg in an editor for a cms?
I agree on everything you said, but you (deliberatly ?) omits some aspects :
- Performance :
No cache for inline svg (same icon loaded on everypage)
One more hit for font
Deeper and more complex DOM with SVG => Slower parsing / css rendering
Overall weight : 37kB of svgs => 6kB of .woff file (as of my current project)
- Style :
Ability to change color of icon via CSS color, but only one color
Complexity of changing SVG color via CSS, but flexibility of colors
- Render :
SVG still has weird render bugs (blurry on IE, …)