I’ve been a big proponent of icon fonts. Lots of sites really need a system for icons, and icon fonts offer a damn fine system. However, I think assuming you’re good with IE 9+, using inline SVG and the First let’s cover how it works. A nice way to handle your icons is to have a folder full of ![]() They can be colored, not colored, multiple shapes, sizes, whatever. ![]() You can let Illustrator (or whatever) save it however, with all the cruft that comes along for the ride:
Combine the .svg filesYou can manually do this if you want. I’ve done it. You don’t even have to look at the final file. Just call it It should just be an
Again you can do that by hand, but of course that’s a bit laborious. Fabrice Weinberg has created a Grunt plugin called grunt-svgstore that automates this. If you’ve never used Grunt, you can do it. Here’s a screencast to get you started. You can install it with:
Make sure the task is available with:
And then in the config:
In the output file,
Inject that SVG at the top of the documentLiterally include it, like:
Or however you want to do that. It’s gotta be at the top, sadly, as there is a Chrome bug in which this isn’t going to work if defined later. Although… there is more to this story because as I type these words, the theme this very site is using has the icons defined at the bottom of the document and it works. Ughkgh confusing. Use the icons whereverNow you can use them wherever! Like:
Note that grunt-svgstore is now using
<symbol> so you don’t even need to use the viewBox!Make sure you use those class names on the svg to size it.
Yay: you can style them (and their parts) with CSSOne of the reasons we loved icon fonts is the ability to style them with CSS. This technique one-ups that in that we do everything we could there, and more, because:
The svg is (kinda) in the DOM, so JavaScript too. Here’s some styling possibilities and a demo of this all at work: Another way: IcoMoonIcoMoon, which is known for producing icon fonts, actually does a fantastic job of producing SVG sprites as well. After selecting all the fonts you want, click the SVG button on the bottom and you’ll get that output, including a demo page with the inline SVG method. ![]() Browser SupportOn the browser support front, the danger zones are IE 8 and down, Safari 5 and down, iOS 4.3 and down, and Android 2.3 and down. But if your policy is “the last two major versions” – you’re looking at pretty much 100% support. Remember that icons can be used as a supporting role only, like always accompanied by a word. If that’s the case, support isn’t too big of a deal. If these are stand-alone, and non-display would make the site unusable, that’s a big deal. I probably would go for icon fonts, as the support there is much deeper. Just make sure you do it up right. This is going to get a lot betterIdeally we’d be able to do this:
This does work in some browsers, meaning you could skip the include at the top of the document. Doing it this way means an extra HTTP request, but that means you can utilize caching more efficiently (not bloat document caching). In testing, Jonathan Neal discovered you need to have the xmlns attribute on the
But even then, no support in any IE. Unless you wanted to swap out the whole
His demo now also has a method which makes an Ajax request for the contents and injects that, which allows the fills to work in IE 9. Not as efficient, but more like a polyfill. I imagine someday straight up Browsers treat ![]() Right now, we can target, say, an individual
But that will affect all instances of that path. You’d think you could do:
But that doesn’t work. It crosses that shadow DOM boundary. Ideally you’d use the “hat” selector to break that:
But that’s not supported yet either and it’s not entirely clear if that’s exactly how that will work or not. “Versus” icon fontsVector-based: tie Style with CSS: slight edge to SVG sprites (targeting parts, SVG specific styling like strokes) Weird failures: SVG seems to just work (when supported). Icon fonts seem to fail in weird ways. For instance, you map the characters to normal letters, then the font loading fails and you get random characters abound. Or you map to “Private Use Area” and some browsers decide to re-map them to really weird characters like roses, but it’s hard to replicate. Or you want to host the @font-face files on a CDN, but that’s cross-origin and Firefox hates that, so you need your server to serve the right cross-origin headers, but your Nginx setup isn’t picking that up right, SIGH. SVG wins this one. Semantics: Not a huge deal, but I think an Accessibility: Maybe someone can tell me? Can we/should we give the Ease of use: Tools like Fontello and IcoMoon are pretty good for an icon font workflow, but the folder-full-of-SVGs with Grunt squishing them together for you is even easier, I think. Ian Feather posted an article about why they switched away from icon fonts as well and I agree with every single point. |
|