Versions Compared


  • This line was added.
  • This line was removed.
  • Formatting was changed.


In our previous exploration of Font Icons vs SVG Icons we adopted Font Icons, mainly because they provided the functionality we were looking for and were broadly supported. However, in practice we've experienced some annoyances with maintenance and usage. With font icons, you need to create a new font family and make use of the PUA value, specified at creation time, to reference the icon in the CSS. A few challenges arose around how to scope the font family. Adding in unused icons results in a font that is too large in size. However, as you need additional fonts, you are required to recreate the font, or link in an additional font. In the case where a font is extended, the creator has to be careful to keep the PUA codes for the original icons the same, else risk breaking existing implementations. In regards to PUA codes, another issue is when a platform already makes assumptions about what a PUA character is used for. ( see: 

serverFluid Project Issue Tracker
 ). There are some build tools for creating the Font Icon, IcoMoon and grunt-webfoot.


The Infusion-Icons npm module can be used to simplify the process of tracking PUA codes and generating icon fonts. See:

SVGs provide the same / better scalability to font icons and don't require hacking the font system to make them work. They also provide the options to support more complex icons including multiple colours. Additionally the source for font icons are SVGs anyways, so we can cut out one conversion step by using them directly. However, they are not without their own caveats. One being the fact that they don't have as broad support as font icons do. In terms of modern browsers this is no longer an issue, although there may be some rough edges if IE 11 support is required. Another issue, has to do with how the SVGs are created/exported in regards to their styles. In particular we want to be able to support easily theming them for contrast modes. 


Code Block
  		<use xlink:href="icons.svg#icon1" />


One solution for styling is to remove all of the default values for fill and stroke from the svg ( this can be done as part of the build process by grunt-svgstore. In the CSS for the page, you could set the fill colour to "currentColor". This will take the value of the inherited or set color. It is possible to set the fill or stroke color in the svg itself to "currentColor" which provides for two color svgs. However, it does not seem possible to export svgs with this value from Illustrator, and would have to be manually inserted into the SVG itself; posing a maintenance burden.


  • CSS stroke will override a presentation attribute <path stroke="#fff" ... />
  • CSS stroke will not override an inline style e.g. <path style="stroke: #fff;" ... />