Why the #$%& should I use symbol fonts

By  Daniel Simington

Everybody loves decorated text. It makes a heading or special point pop out and draws the eye to the points you’re trying to get across.

And one of the most effective ways to decorate this text would have to be throwing an image in front of it. And for many years now, that’s exactly what we’ve done.

But with the new world order of multiple screens, and multiple resolutions, making these images look their best for all users is a minefield of sizing, scaling and jagged edges.

Yes, you could use SVG for this, but SVG can be unwieldy, and for a long time was not that well supported. And each SVG had to be a separate call to the server, resulting in a performance degradation.

Enter the symbol font.

Symbol fonts allow us to take our current icons and create our own personal font for use on our webpages. These images are scalable, portable, compressible and easy to implement. And there are plenty of people happily giving away complete icon sets that will likely solve most of your requirements. And if you can’t find a free one, there are even more paid options to explore.

You can treat the symbol font just like your normal fonts, they can be fun, elegant, serious, bold or understated. Or all of these at once.

But it’s not just text decoration that allows symbol fonts to shine. Social media, calls to action, link and list decorations are all open for business. Anywhere that you can use text, you can use a symbol font, and in most cases all it takes is a single classname.

You can grab an entire set of symbols from the internet, and many of these are available via CDN (Content Delivery Network). Aside from the general savings of a reduced number of HTTP requests (there’s only one call per font file, rather than one per image), using a pre-packaged symbol font over a CDN will also decrease the perceived load time of your site because these remote files will allow more files from your own server to be downloaded concurrently. The benefit of a CDN is obviously not limited to just using remote fonts, but that’s something best reserved for a different article.

Then it’s simply a matter of setting up the font in your web page like you would for your normal text font, and assigning the correct CSS classes to make the text use this font. You can use the symbol font’s inline as pictographic representations of your words (although this would be at the cost of accessibility) or even as standalone items that are unrelated to your content.

Generally, symbol font characters are assigned to the extended Unicode characters that would not be in use for your audience (such as Japanese Kanji or rarely used mathematical symbols). If you need to use these fonts in your site, you can generally reassign the Unicode character you use, especially if you roll your own font.

One good place to start is at Fontello.com (http://www.fontello.com) which gives you a list of several freely available existing symbol font libraries from which to pick and choose, as well as a method to drop your custom icons (in .svg format) to be used as you see fit. This seems to counter the earlier point of SVG being unwieldy, but creating a few custom SVG icons is preferable to creating your own social media icons (or stealing them from someone else’s site, which is bad. Okay?).

Additionally, in a multiple developer environment like ours, where different people may be working on a mini-project for a client, and our support team is working on tickets for the same client at the same time, the ease of implementation is hard to ignore. There’s no requirement that everyone needs to know how to create and manipulate SVG files, and even if they can do that there’s no requirement for them to also know how to implement the front-end to manage it. It’s simply easier to use a known item like a font-face that’s well supported and well known by any reasonable developer.

Extolling the virtues of this approach also makes designing the site a little easier. If the client is happy to use the symbol font, and any given library has sufficient icons to make their vision achievable, it reduces the load on the designer to deliver an entire new set of icons that will likely end up being a re-tread of someone else’s work. This reduces overall client expenditure, if only by a few hours, reduces some stress for the designer, and makes it easier for us to build the site, as we have prior knowledge of the implementation requirements and limitations. It’s a win-win-win situation.

This is not to suggest that symbol fonts are a silver bullet that will solve all your design woes. For the most part you’re going to be limited to a single colour per-icon. The same way your fonts are currently limited to being the same colour in any given block. It is, after all, just another font you can use.

If you are using any custom symbols, and need to add a new glyph, you’re also in the unfortunate position of having to regenerate your font files again. This is not too bad in practice, as sites like Fontello allow you to load your existing symbol font using the packaged JSON file that comes with the download. You did keep that in your repo, didn’t you? After importing that JSON file it’s simple to add a new glyph and re-export the font as a new set of files. We’ve seen a couple of instances where doing this has resulting in some of the Unicode being reassigned, so you will need to be careful of that.

Additionally, because the browser interprets these symbols as a font, and font anti-aliasing that either you or the browser introduces will be present on these as well. It is sometimes a pain to turn this off for specific items (if it’s even possible in all situations), but it does mean that sometimes the edges of your symbols might not be as sharp as you would expect.

There are alternatives to symbol fonts that don’t have these limitations but they all come with their own limitations that in our opinion (at least in the medium term) make symbol fonts the current ideal way forward.

Inline SVG icons do not have the limitations over font use, as they are simply images. But they are also not cached (because they are fully contained inside a rendered page), and you cannot get the benefits of using a CDN with them. They also offer the ability to change each multiple part of each icon individually, so you can get multiple colours.

Externally referenced SVG sprites can be cached, and will avoid the blurriness of a symbol font, but at the moment support for them is not where it needs to be to use them in prime time. Internet Explorer is mostly responsible for this, and even the newer versions don’t overcome the limitations that stop this from being useful.

Loading separate icons (in whatever format you choose) gives you the ultimate flexibility over the design, but it can be quite annoying to get images and text to line up properly, and that problem is only made worse in a responsive world when font sizes and page layouts can change from one browser width to the next. There’s also the increase in HTTP calls triggered by using multiple images, or the added complexity of styling containers to hold images that are in a sprites image.

As you can see, there are reasons to use a symbol font, and there are reasons to avoid a symbol font. For us, at the moment, the benefits definitely outweigh the negatives. They won’t be suitable for every site, and it’s almost certain that something new will come along that makes them seem as quaint as table-based layouts, but for now they’re a good every day solution for a very common problem.