August 12, 2013

Icon Fonts, Planes & Browsers-What's Missing?

Articles relating to the magic of icon fonts are being published at an ever increasing rate. They have various methods of getting their ideas across, but the general theme revolves around ease of implementation, and efficacy when used in responsive development.

No longer do us designers have to worry about exporting multiple versions of our icons. This can now all be done by code. Need to adjust the colour? CSS. Need to change the size? CSS. Need to swap out an icon? ...well, you get the point.

Not only does this improve the development portion of a project, it also saves an incredible amount of time spent in Photoshop documents. Font packages such as the ones offered by Symbolset further improve on this time saving by allowing us to use common keywords to render these icons.

Pretty amazing huh? ...not quite. Things fall apart quietly in one important category: Cross browser support.


Now, many will claim that all of these font icons work flawlessly in every browser under the sun due to the various @font-face formats provided, along with the use of Unicode for rendering.

To save everyone a lesson on how Unicode functions, Joel Spolsky has a great introduction into the world of code points.

The issue I am getting to relates to planes that Unicode has reserved for various glyphs, and browsers that don’t support anything beyond the standard Basic Multilingual Plane.

In language I understand, this means that certain legacy browsers (Safari & IE in particular) do not have support for Unicode code points that contain more than 4 characters.

An example of this would be trying to output the search icon using the Symbolset standard library. It's code point "1F50E"€ contains 5 characters, placing it in the Supplementary Multilingual Plane. Instead of getting the search icon, we either get an empty box, or a question mark.

This isn't isolated to just a single icon. These 5 character code points occur throughout the library, and many websites get a spattering of blank glyphs when viewed on a less-than-current iPad or desktop browser.

Now, fall-backs and alternative support methods are still alive and well in the web industry, as it's something we have all come to terms with over the years. What makes these fall-backs and alternative methods effective, is documentation and understanding.

As a relatively new use of an existing technology, icon fonts lack this understanding, along with the proper documentation to ensure that we can resolve these issues quickly, and have alternatives we can call on to resolve these issues.

Despite of slight drawbacks, I will continue to use and advocate the use of font icon libraries such as Symbolset. I just hope that the publishers of these font libraries will inform users and future customers of the inaccuracies of claims of global browser support.