So it's just like a sprite, but with font files?
Web Designers should all be using this idea by now: Font Icons.
11–20 of 78 posts
Re: Web Designers should all be using this idea by now: Font Icons.
#12I 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 ele…
This particular implementation uses CSS before: rules. These are likely ignored by (current!) screenreaders.
Re: Web Designers should all be using this idea by now: Font Icons.
#13They 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.
Re: Web Designers should all be using this idea by now: Font Icons.
#14I 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 ele…
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. See aria-hidden: http://www.w3.org/TR/wai-aria/states_and_properties#aria-hid... Authors MAY, with caution, use aria-hidden to hide visibly rendered content from assistive technologies only if the act of hiding this con…
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.
Re: Web Designers should all be using this idea by now: Font Icons.
#15I 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.
Re: Web Designers should all be using this idea by now: Font Icons.
#16Well, it's a great idea but it doesn't really work in FF 4.0.1 :(
Re: Web Designers should all be using this idea by now: Font Icons.
#17What about browser compatibility? The article doesn't mention how well font icons hold up against different versions of IE.
Does anyone know?
Re: Web Designers should all be using this idea by now: Font Icons.
#18I 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.
It uses CSS pseudo elements, it's not in the markup.
Re: Web Designers should all be using this idea by now: Font Icons.
#19Terrible title to which I have to reply: Web Designers should all have learned to care about accessibility by now.
Re: Web Designers should all be using this idea by now: Font Icons.
#20To 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."