They missed one obvious disadvantage - it doesn't work where users force their browser to use a specific font. All I see are letters instead of icons.
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.
Trying to introduce a design compatible with a user that specifically overrides your design seems like a losing battle, not one that should even be waged.
I think the point is that a user wouldn't know they're overriding the design. When a user sets a uniform font, they're opting to not see whatever font the site was designed for, but it's not at all obvious to them that they'd be messing with icons.
But re-inventing things that already exist is also sub-optimal. Why create a font, why not use an existing standard?
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.
You're describing a weird place where you want to display a semantic document (the html) using some non-semantic style rules (css, specifically :before and :after) and not others (@font-face) and then interpret the result as a whole semantically.
If you want to browser-set font colors, you're going to have a hard time when they match CSS set background colors.
I don't force the font colour in my browser, but I do force the font face, as I have trouble reading sans serif type. (Although I could see why someone might want to force the colours in their global stylesheet for accessibility reasons.)
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
Sometimes we take the whole semantics thing to a point where it's counterproductive. Not every single selector has to be semantic. That's how get into situations like the ones that lead to Nicole Sullivan writing "Our best practices are killing us":http://www.stubbornella.org/content/2011/04/28/our-best-prac...
Wouldn't it make more sense to use a private use area?
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.
I can't find the information, but my understanding is that this approach isn't good from an accessibility standpoint because a screenreader still interprets the icons as their corresponding character and reads that character. As a result, instead of ignoring a checkmark icon, it would try to pronounce it as a single letter.
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.
This is the same problem I have with this approach. It seems like a cool idea, but I don't want to break accessibility. I think you can get around this using aria and having it skip over that element.
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.
I may be misunderstanding the spec, but it looks like you have to be able to set element attributes for this approach to work, which I'm fairly certain you can't set with CSS. And I guess even if you can use JS to set the attributes, there's no way to set them on a pseudo-element anyway.
Do screen readers parse CSS in their reading? I would think this would avoid that problem by using the :before pseudo classes rather than injecting it into the dom directly.
I have been using this method for nearly a year on various projects and theme designs. The font icon method is incredibly useful when you want to give user the flexibility to change up the color of the icons. Plus, as mentioned using CSS pseudo elements with content should not effect modern screen readers.
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
I would love to, but in our case the two limitations are Internet Explorer 8 (and below) and cross domain limitations for the IE work arounds. The specific projects we're using the Pictos icon font on are being served up from a secondary asset server were we have no ability to add cross-domain policies or .htaccess modifications required for SVG or the .htc fixes.
I really don't see that this is a good idea. Icons are by definition graphical, they aren't textual. I can see the draw of having vector icons; but we have other technologies for that.
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.
I do agree with you, but have you checked the Unicode tables recently? We already had "black queen" and "snowman", but Unicode 6.0 brought us, among others, "Smiling face with horns", "Cat face with tears of joy", and "Hear-no-evil monkey".
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.
And if your user visits more than one page on your site, you've successfully killed asset caching. More data for your server to send _and_ a slower experience for the user, losses all round
True, there is no caching. But that's still a technique worthy to use when they are very small (hundreds of bytes), or when the images should never be cached (eg. low-resolution real time status graphs). In these cases, they reduce the amount of data on the wire (no extra HTTP requests) and reduce page load time.
To me this seems like an ugly hack to get around flaws in the HTTP protocol. There was an article on HN yesterday about SPDY (http://www.chromium.org/spdy/spdy-whitepaper), a transfer protocol that allows multiple concurrent requests over a single TCP connection. This seems like the proper solution to the primary issue (requesting several small files is slower than requesting one large one). Also, as the design goals for SPDY state, this has the benefit of "avoid[ing] the need for any changes to content by website authors. The only changes required to support SPDY are in the client user agent and web server applications."
It's also an ugly hack to get around the fact that making production graphics for every single icon in every single size/color you may need introduces some serious friction to the development process.
That's only a problem if you lack the proper workflow. If you design your icons in Illustrator using the pixel grid, you can export at any size while remaining pixel-perfect.
This is also true with Inkscape for those with open-source workflows. Also, since svg is a text format, it is simple to batch replace colors in a set of svg files.
It's not even a solution to that problem. If you're willing to compile your icons into a single file you can spend half the effort on a sprite sheet, which is also one request.
Disqus uses this technique to inherit the font color of the embedding page,
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.
Disqus is already using a load of JavaScript, I don't understand why they couldn't grok for the color and then set it as a background color for some transparent icons, or some such.
This is a sloppy abuse of typefaces. You can already base64 your icons in CSS, and you can already package them in sprites automatically with tools like Compass.
This creates more problems than it solves. IE9 will have SVG and SVG support gets better every day.
It misses one huge disadvantage: lack of pixel-level control. There is no way to have really sharp and nice edges on TTF icons, they look all smudgy and just not up to good designer's standards, especially at small sizes.
Wrong; TTF (and most other vector typeface formats) support "hinting," which provides metrics to handle glyph appearances at small sizes on low resolution displays.
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.)
The post acts as if the idea is really new (some article is said to have introduced the idea "one week ago") but I have seen this in practice at least months ago. It’s not a new idea. But there are reasons it hasn’t taken off like crazy.
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.
yeah, i'm really not sure what's new here. but then again the article is from May 4, 2010. i can't remember that far back, but i'm not sure if it was a new idea then, either.
Always amused when I am unable to read an article about the new best practices in web design because the page renders with strange overlapping text. I think the table of short terms near the top is supposed to be an example of icons, but I see nothing in Linux Chrome.
one thing I'd like to scream from the rooftops about Web fonts in IE, though: IE respects the TrueType/OpenType embedding level, but at least some other browsers (last I checked) don't. if your Web fonts are set to an embedding level below "installable", IE will refuse to embed them and use the default font instead. double-check to make sure your font embeds properly in IE 9 before pushing to production.
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.
iconic_stroke.otf"
(this error taken from the link in the OP, the icons on which completely fail to render properly in IE 9.)
I did this half a year ago on neovella.com. It seemed brilliant at first, but ultimately failed for two reasons: A) cross-browser compatibility for @font-face can be a real hassle when you're juggling a few different filetypes and trying to be compatible with everyone; B) filesize of the fonts themselves outweighed their aggregate image-counterparts.
I generally like to think that icon use should be handled as part of the CSS, as it's a design element and not part of the document semantics. Putting it in the markup means that if the design is updated, the markup is still stuck with the old icon, which means it's more work to update the site.
Not switching that fast. The few advantages are size/load time as well as switching effortlessly color. But at the price of
... compatibility, accessibility, rendering (white on black background issue with fonts), single color icons, delayed loading(sometimes fonts load after the page)?
I don't see this as more than a gimmick (a nice one, sure). You end up with mute, non-semantic icon names (single characters) in your CSS, single-color icons only. Vector graphics are nice, but then you might as well go for SVG.
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.
There is another disadvantage of this approach: many times, icons carry no semantic information at all, just being a design thing. Therefore they are most often (and most correctly) implemented as a background image on a certain HTML element which does carry semantic meaning, like a link or a button.
This approach introduces icons within the semantic markup and/or content, unless they're added by some script, which kinda beats the purpose.
Then again, you could also do that in images. Especially if you have some graphic effects like feather, gradient and drop shadows, the advantage of client-side rendering is not entirely clear. If anything, it makes the site heavier to render.
(sure, you get scaling for "free" because it's vector, but in many cases you don't need to use the same icons in multiple sizes on the same device/page, so you could do that as well offline and simply fetch the right image...)
Wouldn't an image strip of your icons (Google does this, 2D video games have been doing this since the dawn of bitmaps) solve one the complaints rather easily?
Personally not impressed by the random CSS3 based animations from a compatibility perspective.
This seems like a step backwards for accessibility. Screen-reading software would end up reading various individual letters to (probably confused) low-vision users.
There may be a good use-case somewhere but please use with caution.
Data URI's are probably a better solution for small images. You cut out the extra requests but don't have to worry about downloading massive font libraries.
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.