Now, I realize this is a demo, but aside from that, I really don't think things like this should be used in a final product.
Why? CSS wasn't made for this. We have SVG for graphics like this. This is a demo, yes, and it's great to demonstrate the capabilities of CSS for making small graphics, but in practicality, I don't see the point. The key problem is graceful degrading- there simply is none here.
Regardless, I love seeing things like this, and he's done a good job. Good work.
I completely agree that it isn't something to be used as a replacement for sprites or SVG. I tried to make it clear that it's nothing more than a technical exercise that I hoped to learn from. Hopefully others will pay attention to that fact and avoid plaguing the web with 'css icons' when there are better (and easier to use) tools for the job.
You're right, people will just continue to plague the blogosphere with posts about how they laboriously drew yet another piece of vector art in 'pure' CSS.
I wonder if the results were more due to the face that the sentence itself is longer, rather than the specific words used (a longer sentence being a larger target for the user's eyes to land on).
Pretty interesting how this has been picked up by so many, and now, at least to some is getting annoying.
I presume Dustin's audience is very "niche". They were responsible, if you will for the conversion results in his article, and after the article are annoyed by it.
For monochrome icons, using font-face seems like a better idea than CSS. You get a ton of icons in one cacheable packet and can easily change the color, drop-shadow, opacity, etc using standard css.
The ideal solution (neither SVG or CSS) should be to use appropriate Unicode characters, of which there are very useful ones added in Unicode 6.0. The very first icon, "search", can be done with U+1F50D LEFT-POINTING MAGNIFYING GLASS. Of course most users will not have appropriate fonts installed for comprehensive Unicode 6.0 coverage, so you should deploy a custom font using @font-face that suits your site. For example, the search box on my personal website uses LEFT-POINTING MAGNIFYING GLASS and a custom font I made that defines a simple magnifying glass much like the one in this demo.
Do you mean Symbola, a Unicode 6.0 font? And yes, but it has elaborate characters that only look good at 40px+. I wanted a much more simplistic style, so I made my own U+1F50D.
Ugh, too clever for my taste. I would hate to edit icons that are a mish-mash of CSS backgrounds, rotated boxes, and border-radius'ed edges, and to boot, based entirely on pseudo-elements. (Current web dev tools like Web Inspector in Chrome/Safari, etc. aren't well built for examining pseudo-elements.) This CSS uses ~3-4 pseudo-elements per icon. It's clever for doing that to preserve the markup and avoiding JS, but it's hard to understand. Maybe it would help to comment the CSS so designers can see that "this is the handle of the trash can, this is the left side of the heart," etc., since :after and :before are hacked far beyond having any semantic meaning.
As pseudo-elements, :before and :after don't have any real semantic meaning. But yes, it is a complete abuse of pseudo-elements that isn't immediately understandable. There are some more practical and simple pseudo-element hacks too - http://nicolasgallagher.com/multiple-backgrounds-and-borders...
Eh, some pseudo-elements have semantic meaning. My best example of this would be :link, which distinguishes between hyperlinks and bare anchors. I would typically associate :before with styling that happens visually before an element, and :after the opposite, but they have been both used here to provide for an icon before the element.
I have noticed that recently the Chrome web inspector has gotten much better at working with pseudo classes. Maybe it is just the nightly version of Chrome, but when I inspect one of those links, I can see and edit the a:before pseudo class.
It's a really nice upgrade, because in the current version of Firebug and older versions of the Chrome inspector it was not possible to modify or even see these properties.
We use a pretty nifty technique that isn't CSS for rendering icons on the blip.tv HTML5 player. Depending on the context, we use a <canvas> tag to display either the vectorized or rasterized version of the icon. For the player itself, not a single image request is required for the thing to draw. And we don't run into the nasty anti-aliasing stuff you see with small icons and <canvas>.
Do you load the rasterized image using a base64 url, or do you store specific drawing instructions in JavaScript (lineTo, moveTo, etc)? For the vectorized icon, do you load SVG inside canvas, or just display SVG directly?
Also, how do you fall back for older browsers that do not support Canvas or SVG?
Performance -- even if the CSS is the same size as the image, a single CSS file can return all the icons with a single HTTP request, vs having to make separate requests for each image.
Even with CSS Sprites, there are two requests - one for the CSS, another for the sprite image file.
Unless you use data: URIs and base64-encode the images, which can result in a smaller CSS file than "pure" CSS while still eliminating extra HTTP requests. That depends on the complexity of the image and of the gradient set (or what have you) that would be needed to replace it. Optimization is always situational.
Oh great, I once felt the need of it, but did not it actually existed. I feel though that pure CSS solution would be better, since modifying the colors etc would be easier with pure CSS.
The main advantage of CSS is that you can change the color and appearance of components without using a graphics package, and they might scale better. But that's about it.
It was a technical exercise rather than a proof of concept. The icons themselves are very simple and limited. I wouldn't recommend using CSS in this way for production work (other than perhaps for very simple arrows).
I'm not sure some simple arrows can be achieved with unicode characters...nor would you want a screenreader to pay attention to what is purely presentational.
To see something like this in action, this HTML Mail.app clone demo (that I'm pretty sure hit the HN front page several months ago) uses data URIs for all its icons:
http://ukijs.org/mail/index.html
In theory, but looking across browsers shows that you'd never be able to use this in production without falling back to graphics, which adds to production, maintenance and degrades any performance benefits for a good portion of users.
It's a nice theoretical challenge, and may provide some benefits if you are building (mobile) device specific systems, but as a broad technique there is little production value at the moment.
Oh, it's because I have enabled "Text-only zoom" in Firefox. I expected the icons to be sized in "ems" so that their size would be relative to their element's font size.
It's interesting to see these icons and actually recognize what sites already use them. For example, I believe OKCupid uses several of these icons in their GUI such as the report flag, edit, views, etc.
Why? CSS wasn't made for this. We have SVG for graphics like this. This is a demo, yes, and it's great to demonstrate the capabilities of CSS for making small graphics, but in practicality, I don't see the point. The key problem is graceful degrading- there simply is none here.
Regardless, I love seeing things like this, and he's done a good job. Good work.