Seriously, Don’t Use Icon Fonts

Written by Tyler Sticka on

Icons are everywhere. These “little miracle workers” (as John Hicks described them) help us reinforce meaning in the interfaces we design and build. Their popularity in web design has never been greater; the conciseness and versatility of pictograms in particular make them a lovely fit for displays large and small.

But icons on the web have had their fair share of challenges. They were time-consuming to prepare for every intended display size and color. When high-resolution displays hit the market, icons looked particularly low-res and blocky compared to the text they often accompanied.

So it’s really no wonder that icon fonts became such a hit. Icons displayed via @font-face were resolution-independent and customizable in all the ways we expected text to be. Sure, delivering icons as a typeface was definitely a hack, but it was also useful, versatile, and maybe even a little fun.

But now we need to stop. It’s time to let icon fonts pass on to Hack Heaven, where they can frolic with table-based layouts, Bullet-Proof Rounded Corners and Scalable Inman Flash Replacements. Here’s why…

Screen Readers Actually Read That Stuff

Most assistive devices will read aloud text inserted via CSS, and many of the Unicode characters icon fonts depend on are no exception. Best-case scenario, your “favorite” icon gets read aloud as “black favorite star.” Worse-case scenario, it’s read as “unpronounceable” or skipped entirely.

They’re a Nightmare if You’re Dyslexic

Screenshot of icon issue after replacing fonts on GitHub

Many dyslexic people find it helpful to swap out a website’s typeface for something like OpenDyslexic. But icon fonts get replaced as well, which makes for a frustratingly broken experience.

They Encroach on Emoji Turf

Most of the time, we rely on automated tools to choose which Unicode characters are assigned to which icon. But Unicode’s also where our beloved emoji live. If you aren’t careful, they can overlap in confusing (albeit hilarious) ways. My favorite example: Etsy’s “four stars and a horse” bug. More recently, our own Jason Grigsby encountered random fist-bumps on ESPN’s site.

They Fail Poorly and Often

Microsoft's example missing glyph characters

When your icon font fails, the browser treats it like any other font and replaces it with a fallback. Best-case scenario, you’ve chosen your fallback characters carefully and something weird-looking but communicative still loads. Worse-case scenario (and far more often), the user sees something completely incongruous, usually the dreaded “missing character” glyph.

Custom fonts shouldn’t be mission-critical assets. They fail all the time. One look at Bootstrap’s icon-related issues and it’s no wonder why they’re removing them entirely from the next version.

Worse still, many users will never see those fonts. Opera Mini, which frequently rivals iOS Safari in global usage statistics with hundreds of millions of users worldwide, does not support @font-face in most cases. Opera recommends avoiding icon fonts if you want to support Opera Mini.

They Never Looked Right

Detail of Stackicons' octocat in IE11

The way browsers hint fonts to optimize legibility was never a good fit for our custom iconography, and support for tweaking that behavior is all over the place.

Multicolor icons are even worse. The technique of overlaying multiple glyphs to achieve the effect is impressively resourceful, but the results often look like their printing registration is misaligned.

You’re Probably Doing It Wrong

“But Tyler,” I hear you say. “You’ve completely ignored Filament Group’s Bulletproof Icon Fonts, complete with feature tests and sensible, content-driven fallback solutions.”

And you’re right. Those techniques are great! If you’re using an icon font, you should definitely follow their recommendations to the letter.

But you probably won’t.

What you’ll probably do is adopt whatever your framework of choice has bundled, or drop in some massive free icon font you can use right away. You won’t modify how they work out of the box because that’s really hard to prioritize, especially when they look great on your monitor with virtually no effort at all.

Or maybe you will do the work, designing and curating a custom icon font, choosing your Unicode characters carefully, documenting and evangelizing the importance of implementing your icons in an accessible way with appropriate fallbacks. Then one day, Dave forgets to add a fallback image to that iconographic button he added (which looks great, by the way), which Roberta reuses for her related Pull Request, and before you know it, your app has devolved into a fragile, hack-littered wasteland once more.

These examples are not hypothetical (though names have been changed to protect the innocent). I’ve seen them happen to multiple organizations, all of them starting with the best possible intentions.

There’s Already a Better Way

SVG is awesome for icons! It’s a vector image format with optional support for CSS, JavaScript, reusability, accessibility and a bunch more. It was made for this sort of thing.

But I hear a lot of excuses for why teams avoid using it, even for brand-new projects. Here are a few…

“SVGs can’t be combined into sprites.”

They totally can. There are even really great tools like svg-sprite and IcoMoon that can help automate that process.

“SVGs are larger in file size.”

Usually when I hear this, the team’s comparing a single binary icon font to multiple, uncompressed SVG files. The gap narrows dramatically when you optimize your SVGs, combine reusable ones into sprites, and deliver those with active Gzip compression or embedded in-page.

Occasionally I’ve heard the gap is still too wide when hundreds of icons are included. This begs the question: Why are you including hundreds of icons on every page?

“The icon markup is too verbose by comparison.”

Let’s compare:

<!-- Typical @font-face icon: -->
<span class="icon icon-search" aria-hidden="true"></span>

<!-- Typical SVG icon: -->
<svg class="icon">
  <use xlink:href="path/to/icons.svg#search"/>
</svg>

The SVG markup is barely more verbose, and way more descriptive and semantic than some empty, ARIA-hidden <span> element.

“Browser support for SVG is worse.”

As of this writing, global support for SVG is up to 96%… 4% higher than the same stat for @font-face. Plus, SVGs are way more accessible and their fallbacks are much more straightforward.

“The framework we chose already has an icon font.”

If your framework told you to jump off a bridge, would you?

Don’t Be “Table Guy”

I was in school when the Web Standards movement hit critical mass. While the majority of my instructors saw the merits of semantic markup and embraced it wholeheartedly, one passionately held out. “Table Guy” argued that no layout tool could usurp <table>, that it was inherently better-suited for crafting grid-based designs. He boasted of how quickly and easily he could achieve the “Holy Grail” layout with his trusty table cells. He cited the wealth of cross-browser inconsistencies that continued to plague CSS.

Table Guy and I kept in touch. Today, he freely admits he was wrong about CSS. He feels embarrassed to have been so married to a technique that was so clearly misappropriated in hindsight.

If you won’t stop using icon fonts for people with screen readers, people with dyslexia, people with browsers that don’t support @font-face, people who randomly didn’t load the icon font once for some reason, or designers who just want their icons to look right on-screen…

Then do it for yourself. Don’t be Table Guy.


Never miss an article!

Get Weekly Digests


Comments

Hey Tyler,
Nice article - definitey educational.
A few questions:
1. Your fallback example shows lots of ways to fallback. Are those meant to be alternatives, or are you recommending people literally add all of them to their code?
http://cloudfour.github.io/slides-svg-101/#/23/2

2. One of the great benefits of an icon font is the css reuse. For example, I can place an icon on a button or in a heading, and it's automatically the right size & color. SVG uses different css attributes for color - so I think I have to add an SVG sub-class to all the stuff to make it work. Is that right? Any tips on how to practically approach this?

Replies

Hi, Elise! Thanks so much for the kind words. :)

1.Which fallback you used depends on how you've included the icon (either svg, object, img or via CSS). I probably should have linked to this great post on CSS-Tricks which goes into far more detail than my slide.

2. By using the currentColor keyword, any SVG property can inherit the text color of its parent element. Where you use currentColor exactly depends on your project... you could apply it from your site's CSS, from the CSS of the asset itself, or via element attributes. If you're sure all your iconography will be monochromatic and will consist of fills (no strokes), then it makes sense to just apply that rule once via your site's CSS. But if you want the freedom to pick and choose which aspects of your icon inherit the text color and which don't, it might make more sense to define that in the asset itself.

Actually, with SVG if you use 1em for width and height in CSS it WILL equal the size of its parent font-size. On the colour front, setting fill: currentcolor; means it will be set to the parent elements colour. This even works for :hover, :focus etc.

1. Both examples are technical issues that can be easily fixed with technology (e.g., add an attribute to icons to tell screen readers and dyslexia programs to ignore them, and since we already add a title to them, that can be used instead)

2. see #1

Anger Clouds the Mind

Replies

Not to mention...

Why would a screen reader read text from the part of Unicode that is designated for custom characters? This isn't a problem with icons at all. It's a problem with screen reading software.

Hi Anger,

Thanks for commenting.

1. "Many dyslexic people find it helpful to swap out a website’s typeface." This can be accomplished with user style sheets or extensions. Telling the browser to ignore the icons doesn't solve this problem.
2. Telling the browser to ignore the icons wouldn't solve ESPN's home page showing fists instead of down arrows or Etsy's four and horse stars example. Neither have anything to do with assistive technology and everything to do with icon fonts being a hack that fail in tragic ways when things go wrong,.
3. As for why screen readers would read text from the Unicode, maybe you're right. But it doesn't change the fact that their current behavior is often to read the characters aloud. Perhaps you can convince them to change the behavior. But until they do so, it is a disservice to people using assistive devices to continue to use icon fonts.

Icon fonts are a brilliant hack, but like many hacks, they are brittle. SVG was designed specifically for this type of use which makes it more reliable.

-Jason

I tried the OpenDyslexic extension for Chrome. It didn't interfere with icon fonts. See this screenshot: https://pbs.twimg.com/media/CUlCVnzVEAALw7S.png:large

Even if it did, it would have been a bug in the extension. You can specify a code range in your @font-face rule so that only those characters that are supported by the target font are affected.

Also, as I mentioned earlier, this statement that icon fonts are a hack is incorrect. Fonts are meant to be used for letters as well as icons. If that wasn't the case, Emojis and the Private Use Area in Unicode wouldn't have existed.

Not every person with dyslexia likes OpenDyslexic... some prefer Dyslexie or even Comic Sans (!). The second dyslexia extension returned by a quick Google Search (this one) still breaks icon fonts.

I agree that developers should improve their extensions. But if I can use a different technique today that sidesteps the issue entirely, that's really compelling to me.

That's a good point. But I'd rather report such bugs so that we can have the option of using both techniques (SVGs and icon fonts) available to us. This situation is similar to how it is sometimes encouraged to use a new good standard implemented in a browser, to pressure other completing browsers to also implement the new feature/standard.

> So it’s really no wonder that icon fonts became such a hit.
For me, it’s such a hit because icons are becoming now an alphabet! They have now Unicode characters, they are becoming letters like in any natural language alphabet. On the other hand, icon fonts adhere to the right Unicode addresses, mean that user may find a corresponding fall-back glyph in his client-side environment.
> Worse-case scenario, it’s read as “unpronounceable” or skipped entirely.
If the font adheres Unicode addresses, we can’t blame the font here, it’s screen-reader fault!
“SVG Sprite Creation Techniques” article is really interesting, thank you and Sara, but it’s still another hack.
Generally speaking, I believe there must be a CSS pseudo element called `:icon`:
http://richstyle.org/icon-standardization-for-web-applications.php
I mean W3C should acknowledge that there’s something in this world called icon!

Replies

Adhering to "the right Unicode addresses" assumes that there is a Unicode equivalent for every icon (which is often not the case), and that every Unicode character is implemented consistently across every platform, which is rarely true.

As Jason said in his previous comment, maybe screen readers should change their behavior. But that doesn't really help any of our users today.

Interesting article. I'd be all for ditching icon fonts but after reading the linked article by Sara Soueidan (https://24ways.org/2014/an-overview-of-svg-sprite-creation-techniques/) I'm not sure I'm sold on the techniques for implementing the SVG alternatives.

In your article you reference the global support for SVG being higher than the support for @font-face, but that's only for basic support which is a little bit misleading. Support for using an SVG fragment identifier like the one being used in your markup example has a significantly lower global support of 80.34% (http://caniuse.com/#feat=svg-fragment). The linked article also points out that no version of IE supports referencing an external file from within a tag. That is going to lower the support of that specific example around another 8%. It looks like there is a polyfill but isn't that just trading one accessibility issue for another by introducing a JavaScript dependancy?

I've noticed that Sara's article is from almost a year ago so I'm not sure if anything has changed. I'd be really interested in an up-to-date article that focuses on whatever is currently considered to be the best SVG icon technique. It would be good to see a weighing of the pros and cons of that versus @font-face and to see a more in depth guide of that technique with any required fallbacks in place.

Replies

Great points, Grant! I know that Sara is planning to write an updated post on sprite techniques, so I'd look out for that. We tend to use the afore-linked svg-sprite module, usually in conjunction with a build tool like Gulp or Grunt.

You're right that SVG fragment identifier support is lower (though I'm super excited that Microsoft added external content support in EdgeHTML 13). But SVG can also be embedded via img tags, object tags or via CSS. That does mean you need to create fallback images if you want to use the svg element in older browsers, but you should already be doing that for icon fonts anyway, right? ;)

Another point to consider: SVGs have built-in fallback methods, most without any JavaScript dependency. Worse-case scenario, your image doesn't display. Icon fonts lack any non-JavaScript fallback mechanism, and when they fail, they litter the page with Unicode characters.

Thanks, I'll keep on the lookout for the next article and I'll give that technique another look. I've been using SVG pretty frequently lately and those SVG fragments definitely look worth exploring regardless. Glad to hear that Microsoft will be adding support.

Good point about the Unicode characters on failure. It's definitely a more elegant worst-case scenario.

Correct me if I'm wrong but the technique in that CSS Tricks article looks like it is still using fragment identifiers which means support is still only just a smidge above 80%. In general, SVG support is great! It's the use of fragment identifiers that is the limiting factor in these techniques. There are situations where SVGs are supported and fragment identifiers are not (iOS prior to v8 and Android prior to v5). I'm still not entirely clear on what the appropriate fallback is in those situations.

I currently just inline any SVGs that I use without using any spriting technique. You can still style things through CSS and you can create fallbacks that don't rely on JavaScript. It works but it's inefficient if you're reusing the images and dealing with more than a couple of icons. You lose out on all the benefits provided by sprites and icon fonts.

I personally use SVGs these days, and I encourage using them as well. But I don't agree that icon fonts are a hack. As Mike 'Pomax' Kamermans put it:

"Fonts are for encoding vector graphics that are to be used in typesetting context. That can mean letters, or icons, or emoji"

There are clear definitions for icons in the Unicode. Perhaps icon fonts should be made & used as if they were custom emoji fonts. Something like this: https://codepen.io/Keyamoon/pen/jboVPO

This method should solve all the problems mentioned in the article; except for multicolor icons.

Wouldn't it be better if we had two decent solutions to the same problem, instead of only one? Web seems to be usually like that. There are many different techniques for solving the same problem. There is no one right answer. We still use tables when it's appropriate. We can keep icon fonts in our tool belt and use them when appropriate.

Replies

See my response to Anas' earlier comment. It's a nice idea, but it relies on designers only using icons that exist in the Unicode spec, are read aloud by most screen readers in a manner that's accurate given their context, and that are consistently supported across all platforms. That's a tough set of requirements!

My main point was that icon fonts are not a hack. Fonts are meant to be used for icons too. If that wasn't the case, Emojis wouldn't have existed. Also, private use areas in Unicode were designed to be used for custom glyphs. Your article labels icon fonts as a hack, which is wrong.

I just tried Apple's VoiceOver again. It doesn't pronounce anything if you are using Unicode's private use area. You can make VoiceOver read what you want if you put a label in a visually hidden span.
May I ask which screen readers that you tested fail?

As I mentioned earlier, I use both SVGs and fonts. We should be able to use both techniques.

Firstly, I don't find "hack" to be an inherently negative term. The web is full of really useful hacks.

I also agree that if by "icon font" you mean "font that includes custom designs for standard Unicode characters and emoji," there's nothing inherently hack-y about that.

But an icon font where characters (some of which have no Unicode equivalent) are mapped to random glyphs, which are injected into a page via CSS content attributes, which (best-case scenario) are hidden from screen readers using a combination of `speak: none` and ARIA attributes? That feels pretty hack-y to me. And that's how the majority of icon fonts are implemented, which is why the emoji bugs like "four and a horse stars" and "more fist-bump" happen.

Voiceover improves with every OS version (assuming everyone upgrades, of course), but there are still plenty of characters with less-than-ideal results. I keep seeing more and more developers using U+2630 as a hamburger icon despite it being read aloud as "trigram for heaven."

Negative or not, I hope you realize that fonts are meant to be used for delivering icons as well as letters or other symbols. PUA exists so that we can define our own custom glyphs. And as far as I've tested, they won't map to random emojis.

In my VoiceOver test, I didn't need to use the ARIA attribute or `speak: none`. All I did was I used PUA for my character codes.

Any technology could be used inappropriately. That doesn't mean that the whole technology should be avoided. Wouldn't you prefer to be able to use both SVGs and fonts? I would, and I do use both.

I agree that icons are one possible use-case of Private-Use Characters. That said, the non-standardized nature of the PUA means there's no guarantee that characters there will be conflict-free, but that's a bigger discussion. I'd love to see more "emoji" or "symbol" fonts that act more like fonts and less like custom UI icon frameworks. I think that'd be swell.

Thankfully, I don't have the power to take away everyone's icon fonts. As mentioned in my response to Gabriel, I love that IcoMoon supports both.

I haven't used icon fonts for a few projects now. I don't miss them. I've been enjoying all the benefits I described in my post (and more). I get irritated when icon fonts fail, which happens to me a lot. I get even more frustrated when I hear the bigger issues they can cause for others. But if a developer eventually demonstrates a way of using icon fonts (or any other technique) that's even more accessible, flexible and fails at least as gracefully as SVG, I'll happily switch to that.

FWIW, all sprite techniques have decreasing value as HTTP/2 becomes more prevalent. Spriting and concatenating files all end up being anti-patterns when it comes to HTTP/2.

As Tyler mentions, there are tools to make SVG spriting and the fallbacks easier. But if for some reason that turns out to be too tricky to get working in a given environment, maybe instead the time could be invested in moving to HTTP/2 and ditching sprites altogether.

/me throws curveball into discussion then runs away…

An additional thought: you cannot simply change colors of SVG icons by CSS classes. You'd need some logic in the SVG file which is not coupled with your website and thus not as dynamic. Was always a deal breaker in my projects.

Just wondering, what do you think of ligatures? http://google.github.io/material-design-icons/#using-the-icons-in-html

Lim Chee Aun

Replies

Ligatures can work, provided you use the text _only_ as mnemonic, and don't expect it to be used by a screenreadder. You'd have to mark it as aria-hidden="true" and provide appropriate alteranate text (eg. using clipped/hidden text span). It's no better or worse than using other code points in that respect.

You can't use the ligature text as-is for accessibility because:
(a) it doesn't localize: "face" might be fine in English, but you'd likely want to expose appropriately translated text in other languages
(b) The meaning of icons can be context sensitive: alternate text should reflect the meaning of the icon, not the presentation. So appropriate alternate text for a face icon could be "anonymous user", or "user is online" or similar - I can't think of a scenario where "face" would be good alternate text - except perhaps in an icon gallery!

One of the reasons I like using icon fonts (specifically FontAwesome) is the ability to insert an icon solely through CSS using pseudo elements. This seems like a truer implementation of what an icon should be: distinct from the content, simply an ornament secondary to the text. I'm not super familiar with SVG, but as far as I know, you need to include them as HTML elements on the page. Is there a way to implement SVG in a similar fashion using only CSS?

Replies

SVG can be used like any other image, so there's no reason you can't insert them via pseudo elements as you would PNGs, GIFs or JPGs. The aforementioned svg-sprite tool even has a CSS-specific output mode. There are also some pretty neat tools for including SVG via a data URI, such as sass-svg.

The drawback of using CSS alone is that the SVG element won't have access to the parent text color, and CSS lacks any built-in fallback mechanism when it isn't supported (you'll have to use a feature test, which relies on JavaScript).

I relate to your initial misgivings about moving some of your icon concerns from stylesheets to markup, but remember: Icon fonts only work because they inject Unicode characters into the page. Even if that content is defined in a CSS file, the end result is basically the same... extra stuff in the page.

You'll probably interested to know that IE9 on WindowsPhone 7 is a great failing case: it DOES support @font-face but WON'T download any font file. I know this is a rare configuration for users, but it still is a good failing case I think.

So even best practice (like using Modernizr) will fail. The only way to succeed is using AdobeBlank font. Pretty hard.

Some readings:
http://blogs.msdn.com/b/thebeebs/archive/2011/12/14/font-face-isn-t-working-on-ie9-inside-of-windows-phone-7.aspx

http://blogs.msdn.com/b/iemobile/archive/2010/11/10/supported-fonts-on-ie-for-windows-phone-7.aspx

http://www.ubelly.com/2011/11/the-differences-between-ie9-on-the-desktop-and-ie9-on-wp7/

Hey, nice article. What do you think of IcoMoon's approach, meaning taking svgs and using them as fonts?

Gabriel Garrido

Replies

You can Import SVGs to IcoMoon in order to export them in different formats, including SVGs and fonts. That doesn't make the font that it generates different from other fonts.

Contrary to my respectful back-and-forth with its creator in this very comment thread, I think IcoMoon is awesome! It packages up SVG sprites and icon fonts really nicely... and in the latter case, it does the best job I've seen of encouraging users to choose reasonable fallback characters. While I personally haven't used its font export for a while now, I'm glad it's still included so that developers can try out either technique for themselves.

This is a great article but I would say you're missing one point ~ which is why I use icon fonts. Icon fonts should be used as accent only and not content ~ following the implementation guides of Filament Group but not relying on them for navigation or content but purely aesthetics/enhancements.

Replies

I love this sentiment, but as mentioned in my response to Alex, content injected via the CSS content attribute (which is how most icon fonts work) is still interpreted as page content by end-users and assistive devices.

If you really want your icons to be 100% presentational, you can use SVG as you would any other image asset in your CSS. No in-page markup required, no Unicode characters injected into the content. But if you want to inherit the parent element's text color, something has to be in the content. It's your call whether injecting glyphs into an empty span element via CSS or referencing an SVG asset directly is the more appropriate approach.

Hi Kevin,

My view on this is that while user interface designers that care about accessibility have two routes depending on what technology is used to convert icons from their design:

- either try to limit themselves in where icons are appropriate according to the implementation guides you mentioned because of font icons accessibility issues

- either being totally free in using icons the way that serves best for visual UX because SVG icons do contain all the semantics needed to know what graphic stands for non-visual rendering

It's a no brainer for me personally and I only use SVG (more specifically I prefer embedding method with references if multiple instances of same icon are used across a document) for icon graphics since I discovered it.

Hope that helps.

Tyler, I think that your point about people making excuses for not using SVGs is spot on. One additional reason is that there is simply just too many different ways of actually implementing SVGs, each with their own pros and cons. Chris Coyier has an excellent article which covers the various methods (https://css-tricks.com/using-svg/) and its clear that this lack of an SVG "best practice" is a legitimate hurdle for its adoption, even when issues like browser support are a thing of the past.

Moreover, the ability to animate SVGs, like what GreenSock has recently released (http://greensock.com/morphSVG) I think really elevates SVG icons to another level. For both designers and developers, the ability to modify the actual code itself means that there is really no limit to what you can do with SVG. Animation is just the beginning.

Resources like IcoMoon, SVGOMG and GruntIcon have been amazing resources for the design community and have reduced a lot of the barriers of entry to using SVGs. I work for a new design/web development startup, Glyphs Company (https://glyphs.co), and we are trying to streamline the process even further. Even though SVG has been around since 1999, it seems like the past year has been a big one for SVG, and the continuing rise of Retina-style displays is going to make having resolution-independent graphics even more important.

Tyler, my friend! Thanks for sharing this article. Couldn't agree more. This stuff needs to stop. I'm going to move to SVG soon on the Circle with Disney site.

You always seem to be a champion of what's right! ?

I completely agree with your article. However, there is one functionality of SVG that is inconsistently implemented in browser that in my mind hurts the adoption of SVG: the ability to include an SVG glyph by ID from CSS as demonstrated here:

http://laurentgoderre.github.io/svg-sprite-demo/

The following syntax is proper SVG and CSS but isn't supported by browsers.

.expand{ background: url(icons.svg#plus)}

You're forgotten one key reason many of us still use icon fonts: a need to support Internet Explorer 8. Some of us still have to support that devil of a browser just from an enterprise perspective.

I would have a hard time getting rid of icons like FontAwesome, IcoMoon etc. for my clients, especially since the Icon fonts are used solely as an accent and never as content.

That being said, there's an overall bigger feel of possibilities in SVG compared to icon fonts. Icon fonts are definitely the lazy way out.

Hello and thanks for this article.
I experimented with a 50 icons pack. SVG sprite = 50 ko (generated with icomoon). Font icon (woff2) = 5 ko.
SVG sprite is very heavy. :/

Replies

I expect SVG sprites to be larger, but not by a factor of ten for fewer than a hundred icons!

I just pulled up IcoMoon and generated a pack consisting of the first 50 of their "free" icon set.

From a fresh download, the fonts range in size from 9.36 KB to 25.1 KB (depending on which format the user's browser supports). By comparison, the SVG sprite is 29.1 KB.

Best practice is to deliver assets with active gzip compression. Once gzipped, the fonts range in size from 4.92 KB to 7.66 KB. The SVG sprite ends up being 7.76 KB.

As mentioned in the article, SVG will typically be larger. But the gap narrows quite a bit if you optimize your assets (manually and/or with tools) and deliver them with active gzip compression.

(I've dropped my files into a Dropbox share if you'd like to check my work.)

Hi and thanks for your answer :)
In my experience, i took the Meteocons pack and his svg sprite weighs 50 kb.

It has just few ko difference once that files are gzipped. Nice !

Hi Tyler,
Here i'm having some doubts ..
1. We can use .svg in websites but we cant use in mobile app design both android & Ios ?
From my point of view if we create our our icons and converting it as a font we can use it for both web & mobile.

If you are using icon fonts, I just found a solution to the problem with browser extensions that allow changing fonts. It turns out we can prevent such issues using CSS! All you need to do is to add !important to your icon font's font-family. Or if you prevent not to use !important, you could use a selector like ".icon, .icon:before".
I have tested this with both Dyslexie and Font Changer. Try icomoon.io for yourself. Its icons won't be affected by such extensions.

I´m fine with SVG in principle, but as far as I know, WordPress doesn´t allow SVG for security reasons.

This has been niggling at the back of my mind for a while... with this post you've really crystallised the arguments for swtiching to SVG and inspired me to start the work of rolling it out on all my sites.

Thanks (I think)

Thanks Tyler for this timely article. I'm currently experimenting using fonts and SVG for a couple of projects. The aim is to have a way to quickly compile a font or SVG sprite (if necessary) to have a set of scalable, per-project, css-aware icons.

Using Gulp, the compilation work can be automated on a comparable way, but what I don't like is the fact that if I use svg-sprites, I need to include the SVG symbols directly on the HTML of every page, that unless you're working on a single-page-webapp, feels bad.

I'm currently looking at sass-svg and other methods that allows some kind of caching, but I'm a bit disappointed that I cannot link and cache the svg-sprinte. Any thoughts? Thanks!

"It depends" is truly the wisest answer any time you ask "should I use this" There was a time when the benefits of icon fonts outweighed the pitfalls. There was a time when tables made sense too. We will always use hacks. Table guy was not a fool.

You actually missed a rather nice example of icon fonts gone rogue: Outlooks default :) .
They use autocorrect to sub it for a 'J' in the wingdings icon font.
So if you've been wondering what those seemingly random 'j's were doing in received e-mails: icon font shenanigans.

I am using SVG where ever I can, however the one thing I find myself being drawn back to font based icons is when it comes to using them in CSS as pseudo classes. I struggle finding a good solution when I have say an arrow icon that is set as ::before content on a .current-page class and I have the same icon used 5-10 times throughout the site in different colors as well as different colors on :hover I could use the SVG as a background image and change the color via one of these methods http://codepen.io/noahblon/post/coloring-svgs-in-css-background-images however this seams like a lot of work (if you can even figure out how to calculate the filter properties you need) to replace 3 lines of CSS with a font icon. I'd be interested to hear how people are dealing with this issue in their workflows.

As a computer scientist, I can assure you that Table guy was right.

"Semantic markup" conflated semantics and presentation from people who didn't know what semantics even means, and as for layout with float and clears, that's probably the worst misapplication of a CSS feature the world has ever seen. (Of course using, CSS as they were initially created, for layout was also a very bad idea from people who knew nothing about layout engines).

Rather than your Table friend, it's CSS that came around, and introduced a few ACTUAL layout methods, like Grid and Flex.


Let’s discuss your project! Email Us