Is it time to revisit font icons

[Justin Obara]

Icon fonts have been on my mind recently. We’ve needed to add new icons for FLUID-5837; which rehashed some issues we’ve come across with font icons, mainly that they are hard to maintain. I was considering writing up a GSoC project idea to help with this and we’ve begun to re-explore some build options ( see: FLUID-5555 ). However, Github just released a blog post detailing how they’ve switched all of their Octicons from icon fonts to svg icons. The TL;DR for the post:

By switching from icon fonts, we can serve our icons more easily, more quickly, and more accessibly. And they look better. Enjoy.

It’s been almost 3 years since we first started to explore using icon fonts. Looking at the TL;DR from GitHub above, you might wonder why we ever went with Icon Fonts in the first place, fortunately we did a good job of recording that information on the wiki ( https://wiki.fluidproject.org/display/fluid/Research+of+viability+of+using+icon+fonts+in+UI+Options ) and have links to the mailing list and the FLUID-4934 JIRA ticket. The gist would be that we had a much more restrictive browser support at the time and using icon fonts were viewed as better option to achieve all that we wanted to (e.g. scale, change colours, etc.). That may not be true today though.

Our current browser support for Infusion is latest versions of Chrome, Firefox, IE, and Safari. A quick look at the caniuse shows that the browser support for SVGs are quite good now, of course with a minor IE workaround. Even with decent support for mobile OS’s.

Am I suggesting to switch because GitHub did it and they’re cool so we should follow them? Well no, and really we should actually put some thought into it. Here are a few of the reasons I’m thinking that it might make sense.

The icon fonts are hard to maintain. When we need to add an icon we have to recreate the whole font or make a new font for the new icons. It’s hard to know exactly which icons are in which font and what unicode value are assigned to them.
We need to create svgs to make the icon fonts from anyways, so there theoretically should be less work
Few people know or easily remember how to create the icon fonts
Won’t lose the icons if a user changes their browser font ( e.g. to a font specifically for dyslexia ), see “Death to Icon Fonts”
Icon Font collisions with expected unicode characters ( see: FLUID-5225 )
Should be easier to styles as we won’t have to use the :before and :after pseudo selectors to add them
Can do other things like animation and multicoloured icons ( if necessary )

Some reasons we shouldn’t change:

Minor IE bug, height and width need to be set for the SVG to render
It seems that inline SVG is the way to go, but that requires more markup in the HTML. We’d need to use inline SVG so that we could do on the fly style adjustments e.g. change the colour for UIO’s contrast setting. 
GitHub has tooling for adding the inline SVG from an external SVG file, we’d probably have to do this by hand, find a tool, or make something.
In our previous round we found that SVGs were substantially larger. Up to 10x the size of icon in a font. We should be cautious of increasing download size especially for low bandwidth concerns. However we may be able to run some optimization on the SVGs to decrease their size and we do only use a few per page anyways.
We should be able make the build tooling to create icon fonts which should reduce the maintenance burdens
Please read the full github post, the “Death to Icon Fonts” presentation, our wiki page, and some of the other posts about this topic that you can find on Google. Let us know what you think is the best solution.

Thanks
Justin

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.idrc.ocad.ca/pipermail/fluid-work/attachments/20160222/6f5a7503/attachment.html>