When it comes to the web, I’m not a fan of sweeping ‘binary’ advice. The ‘don’t do this’ kind of advice is usually too simplistic, idealistic or inflexible; the Web is too grey.

So when Tyler Sticka wrote “Seriously, don’t use Icon Fonts” I felt a little uncomfortable. I understand and appreciate some of the points he raises but I can’t agree with the sentiment that we shouldn’t be using them.

I like icon fonts. I think they are genuinely useful. So I’m here to say a little in defence of icon fonts 😉

I’m not about to tell you should use an Icon Font. I’m here to tell you that I think they are a great solution to certain problems. And certainly more appropriate than SVGs in some situations. If nothing else, I just want to offer some counter balance to Tyler and Sara’s point of view.

I’ve been using SVGs for years; for example I was extolling the virtues of using SVGs as background sprites back in early 2014 so it’s not like I have some agenda against SVG. I just find icon fonts a better solution in some situations.

Need to support Android 2.3?

What browsers do you need to support? For most of the projects I work on I need to consider browsers back to Android 2.3.

Old Android has no SVG support so in these scenarios it’s necessary to consider fallbacks for these older browsers when you are using SVG.

If it’s multi-coloured assets or animated assets, SVGs with PNG fallbacks are the way to go. No contest.

However, there are often a number of graphical assets in a project that are not multi-coloured, nor involved in animation. These are the workhorse assets of a product; arrows, shopping basket icons, refresh buttons etc. These are the kind of assets I generally find better handled by icon fonts.

With an icon font these assets can be resized easily, recoloured simply and they will work comparatively everywhere.

Plus this isn’t a binary thing. You don’t have to choose between icon fonts or SVG with a PNG fallback. Each can solve a different problem for you.

You don’t need multiple font formats

It’s commonly believed you need multiple formats of an icon font (WOFF, WOFF2, SVG, TTF, EOT). You might but you might not. If you want your icon font to be viewable on all devices (apart from old IE) the solution is simple: use a TTF of the icon font. To remove the possibility of the icon font not loading, embed it as a data URI in your CSS. If the CSS loads, the icon font loads.

Icon fonts make it simple to work with designs

With an icon font the designers and the developers have the same flexible asset. Pick the font, paste in the relevant glyph and the size you set the asset in the graphics editor is the size it will end up in the code. Let me re-iterate that point as it’s an amazing benefit of using an icon font. Icomoon has a beautiful feature and I’ll provide a direct quote here from their docs that explains this:

The IcoMoon app aligns the top of the icon canvas to the ascender line and its bottom to the descender line of the font. Using this technique, the size of your font will directly translate to the size of the icon. For example, if you set your font-size in CSS to be 16px, you will get a 16px icon. This method was first introduced by IcoMoon.

So, inside your OS, you install the icon font as you would any other font. In Sketch/Illustrator you select the font, paste in the relevant glyph and size it with text controls as you would any font. That size is a 1:1 of what you will get via CSS in HTML. Size of the shopping basket icon 16px in Sketch/Illustrator? Set it to 16px in your CSS and it will render the same size. Exactly.

It’s not that’s there’s anything wrong with SVG in the HTML for similar utility. It’s just more limiting and you need a shim script to get the solution working well with IE.

PUA and accessibility

Much has been made about the accessibility problems of icon fonts. For the manner in which I apply icon fonts, I don’t believe this is relevant. If you are using an icon font using the private use area of Unicode, starting at a range of e600 (again, IcoMoon has this covered and starts your font at that number by default), screen readers do nothing with it; more simply they don’t attempt to read the glyph. I’m yet to find any evidence of a screen reader reading a unicode number in this range.

Furthermore, I’m using the icon font glyphs as a visual enhancement to something. Therefore, whether the icon appears or not – it is not essential for the use of the interface – you can see this approach in the header icons of this very site.

Using icon fonts in this manner is simple, this is what the PUA looks like in the content value:

.thing {
    /*Other Code*/
    &:before {
        content: "\e600";
        font-size: 1rem;
    }
}

More from the wonderful documentation of IcoMoon:

Some screen readers (such as Apple’s VoiceOver), read the content inside pseudo elements. When you assign single characters to your icons, you wouldn’t want the screen reader to read these characters. By using PUA code points for your glyphs, you can prevent this problem.

So, as far as I am concerned, icon fonts are not a hack. The private use area of Unicode is expressly for custom glyphs. Icon fonts are custom glyphs. Why is this being called a hack? To me it is a text book use case of PUA.

Bonus points for Icon Fonts

With nothing but CSS, you can have text shadows, transition colours, perfect alignment with surrounding text and what’s more the visuals stay out of the DOM. Presentation stays in the presentation layer; the CSS. I’ll level with you though – I don’t actually care that much either way but it might be preferable for you.

Pages render faster with icon fonts

Back in May of this year, Parashuram N did some excellent testing on the comparative speed of SVG and icon fonts. Here’s a headline:

The frame rates were best for Font Icons (sic) and worst for inline SVGs, when measured using request animation frame, and using tracing benchmarks.

These things are always changing. Browsers update, techniques improve but I’ve not seen any data more recently to counter this data. If render speed is a priority, icon fonts are likely a better choice than inline SVGs.

Summary

There are occasions when SVGs in backgrounds are the best choice, there are times when SVGs inline are the best choice. Equally there are times when an icon font could be the best choice. Don’t avoid techniques wholesale. Understand the advantages and disadvantages of a technique fully. Appraise the merits of a technique relevant to your situation and employ said techniques when they are relevant and beneficial.

Learn to use CSS effectively, 'Enduring CSS' is out now

Get $5 off HERE ↠

Write and maintain large scale modular CSS and embrace modern tooling including PostCSS, Stylelint and Gulp