That said, would it not also make more sense to use codepoints within the "Miscellaneous Symbols And Pictographs" range where possible (http://unicode.org/charts/PDF/U1F300.pdf), where you'll find things like volume icons, padlocks, pins, etc. These are missing from my font of choice too, of course, but this seems more in keeping to me with the idea of a semantic web page.
Also, having a list of the icons together with their labels made it easy for me to know what they meant. Some of those icons would be baffling to me if they didn't have a label. I could be convinced that extra visual clutter is a good thing, but some designer is going to have to give a nice example.
If you want to browser-set font colors, you're going to have a hard time when they match CSS set background colors.
Personally, I'm not particularly fond of the use of :before, etc. either (they should be used for purely decorative purposes - the examples in the article seem to be using them to convey meaning), so what I'm suggesting doesn't really make much sense. :P
That would still have the risk of collisions when others use the area for a different character, but at least, the rendering library will have a reason to suspect that may be the case.
Or where the user configures his browser not to use downloadable fonts, like I do.
UPDATE: Further digging seems to validate that most modern screen readers do ignore pseudo elements. So, there's no doubt that this solution is promising. However, as with anything, your user agent baseline should be considered before using it. Saying that everyone should be using this right now probably isn't a reliable blanket recommendation.
Authors MAY, with caution, use aria-hidden to hide visibly rendered content from assistive technologies only if the act of hiding this content is intended to improve the experience for users of assistive technologies by removing redundant or extraneous content. Authors using aria-hidden to hide visible content from screen readers MUST ensure that identical or equivalent meaning and functionality is exposed to assistive technologies.
edit: fuller thought.
One of the disadvantages mentioned in the article is the file size, but it can be drastically optimized. My favorite icon font is Pictos by Drew Wilson (http://pictos.drewwilson.com/). When I use it in a site design I will actually recreate the font file with just the few icons I need, usually 6-8 characters.
To reduce the font file size just load up the icon font in Font Squirrel's font-face generator (http://www.fontsquirrel.com/fontface/generator) and use custom subsetting to specify the needed characters.
Full Pictos Font
EOT (19 KB), WOFF (13 KB), TTF (18 KB), SVG (41 KB)
Total - 91 KB
Optimized Pictos Font (8 characters/icons required)
EOT (6 KB), WOFF (4 KB), TTF (5 KB), SVG (5 KB)
Total - 20 KB
I know people are probably going to tell me an "SVG sprite" isn't possible, but I still maintain that abusing fonts and text like this is a bad idea, even if it does bag you cool CSS3 animations.
Apparently, the world thinks the distinction between text and icon is not that large. Yes, that is mostly for pragmatic reasons, as SMS only does text, and people want to send this stuff using SMS, but it is there, and we cannot deny that.
Given that, I do not think we cannot object loudly against the use of application-specific iconic characters.
Interner Explorer 9 will support SVG. SVG support is getting better every day.
Another alternative for pages with simple icons is to use the Data URI scheme:
To accommodate this wide range of design scenarios, we decided to use our own
custom web font via @font-face instead of traditional raster-based icons. This
provides us with the flexibility of inheriting font color and size from a site’s
existing aesthetic at an incredibly small file size (5kb). Since font-faces are
vector-based, we are able to serve these icons at any size without consequence.
This creates more problems than it solves. IE9 will have SVG and SVG support gets better every day.
The problem, however, is that hinting fonts takes extra work many designers don't bother with, and even if they did, rendering engines may ignore them due to a nasty thicket of patents related to font hinting. (Though I've read that the main ones have expired recently.)
There are still serious disadvantages to (ad least the obvious implementations of) the technique, as powerful as it is when it works right. Others on this page mention drawbacks. Not the least of which: It’s not super easy to make a font with just-right glyphs; you cannot guarantee that no users don’t see or hear letters instead of images or alt-text (ooh! anybody remember our blind/accessible users?).
So until I see a post that examines and solves all the potential issues with icon fonts, I have to stay away.
As pointed out below, this blog post is over a year old. Oops.
Does anyone know?
edit to add: to check, open up the developer tools with F12, go to the console, refresh your page, and make sure you're free of errors like this:
"CSS3114: @font-face failed OpenType embedding permission check. Permission must be Installable.
(this error taken from the link in the OP, the icons on which completely fail to render properly in IE 9.)
If you want fast loading use css+single image robust method as in:
The one valid use case for this is limiting the number of roundtrips & requests. But in the long term, there'll be SPDY (or some other similar protocol) for that. And SPDY fixes the problem for your whole app / page, not just icons.
This approach introduces icons within the semantic markup and/or content, unless they're added by some script, which kinda beats the purpose.
how about using the most common font? (arial) that should take out all your worries on @font-face
Personally not impressed by the random CSS3 based animations from a compatibility perspective.
There may be a good use-case somewhere but please use with caution.
But serving font-face has other issues with even modern browsers - content flash, delayed loading, some need proper mime-types, etc. etc.
I think these icons are great for protyping/design mockups.