I'm a huge fan of icon fonts, but I have a nit to pick with the HTML they chose.
<span class="icon-sm icon-org"/>
That is not valid HTML. The <span> element is not a self-closing tag, so the slash is essentially ignored [1]. Fog Creek's blog is XHTML, so the tag makes sense there, but Trello is HTML5.
It's true that self-closing, non-void elements are not valid. With gzip, it's probably not even worth the savings in size. I know it's bad and we shouldn't do it and it will probably blow up in our face one day, but it doesn't seem to matter in practice and I just like the way it looks.
Somewhat related, i'd really like to see if all this minimizing actually has a notable effect. It strikes me as over-optimising, I mean, i see it all the time, but never _why_.
Save a couple of bytes here and there, and you may save a whole packet; saving a packet when your packet count is small can make a big difference in download times, since TCP slow start means lots of round trips in the beginning of a connection. Also, less data transfered is good for people with data caps, and lets your server do less work. That said, you'll probably get more out of making sure your images are optimized, and apparently changing from sprites to fonts (if your target audience supports it).
I just went through a process of @font-facing a website for one of my projects and I have several things to add:
1. Don't bother with direct font editing. Instead use a vector editor like Inkscape [1] to save your icons as SVG and then convert them to a complete font-face kit with IcoMoon [2].
2. IcoMoon will also let you cherry pick icons from a large number of both free and commercial icon packs. This is a great starting point, especially at the sketching phase.
3. A better way to browse icon packs though is with Fontello [3]. Same packs, snappier interface.
4. FontSquirrel font-kit generator is really good, because it does a great job (re-)hinting TTFs so that they come out looking better in smaller sizes (10-14px)
-- but --
There are fonts that FontSquirrel generator doesn't process correctly. It would happily spit out an @font-face kit, which will look normal most of the time. However on selected Windows boxes the font will render without anti-aliasing, naturally making it look like butt. It doesn't appear to depend on the Windows version (saw it happen on XP and W7) nor the browser (saw it on IE and Firefox). Also, same machines will render all other font-face kits just fine. I spent a couple of days chasing the cause, but then gave up because I found a simple workaround.
The workaround is to serve OTFs. Instead of specifying .eot, .woff, .ttd, .svg in your CSS, list .eot, .otf, .woff, .ttf, .svg. OpenType files are generally heavier, but they also compress better, so it's a wash in terms of a I/O hit if served over gzip'd HTTP.
In other words -
+----------------------------+
| Make sure to test the hell |
| out of your font-face kits |
+----------------------------+
To that effect, Adobe Browser Lab [4] includes a version of Firefox that exhibits above behavior. However, the Lab also includes a version of Chrome that pixelates all fonts, because it appears to run on a machine with anti-aliasing disabled at the OS level (yes, it doesn't make any sense, must be some sort of an inside Adobe joke).
So, the testing strategy is to get a proven font-face kit, like Open Sans, and check that both your font and this litmus font render well. If both look aliased, then it's the OS issue. If only yours does, then it's a problem with the font-face kit.
Awesome. This approach can definitely work for lots of people. We default to WOFF because it's essentially just a slightly more compressed OTF file, it's something all browser venders seem to agree on, and it just seems like The Right Thing To Do for the web. We serve raw TTF files for the stock Android Browser. I had so much trouble hinting the raw OTF font for Chrome on Windows that I gave up and used SVG. As I mentioned in the article, SVG fonts don't get mangled by the browser's font rendering engine or ClearType.
WOFF is a result of font foundries and online font services pressuring W3C to produce a browser-only font format. Something that cannot be save-as'd and dragged into the C:\Windows\Fonts. It is indeed somewhat optimized for the web use, but that wasn't the primary design goal behind it.
Ah, well copy protection is definitely not a concern for us, since we serve the raw TTF alongside the other formats. The fact that the WOFF file was about 30% smaller than the TTF was more of a deciding factor.
If you have the icons as svg you could also try raphaeljs [1][2]. It'll render the svg path as svg on most modern browsers and as vml on older IE browsers (ie6+). The added benefit is that raphael also does animations which enables you to animate your icons on browsers that don't support css3 animation.
Shameless plug but Font Custom [1] will let you generate icon fonts from the command line and spits out all of the file types (eot, woff, ttf, svg) plus a ready-to-rock CSS file for you.
We use icon fonts on my current side project and it is wonderful to work with. We use font awesome (http://fortawesome.github.com/Font-Awesome/) which works well with (or without) twitter bootstrap.
It had greatly improved our UI and sped up development.
As another example of Font-Awesome in production: I've incorporated Font-Awesome very heavily on my own blog, and it works very well: http://minimaxir.com
And have you seen how ugly it looks with Chrome on Windows 7? Which should be the most popular browser + most popular OS. So I disagree with you and the blog author you should use fonts as icons.
They look ugly with Chrome + if fonts are not supported they don't show anything. At least if the image is missing you see X.
The only reason I linked to my blog because it is directly relevant (discussion is about Font Awesome, and I've done a lot of development with it).
If there was a way to show off Font Awesome without providing a link to a case where I actually used it, I would. (screenshots won't be as effective since I incorporate on:hover effects.)
Of course it wasn't the reason nor was it the only one. Please. We are all adults here, we all want to piggy-back on HN traffic, but - c'mon, your blog is not a notable example of the use of Font Awesome "in production".
I think that "Hey, I did something relevant to this discussion!" is a valid reason to link to something of yours. People do it with coding projects all the time.
First, check that your server / the CDN is sending the correct MIME type for each font being served.
Secondly, the Access-Control-Origin-Header must be set to allow cross-domain resource sharing - Firefox doesn't permit cross-origin fonts by default, unlike Chrome and other browsers.
Isn't there a massive unspoken constraint: you can only have monochrome icons? The sprite they show is impossible to reproduce: look at the "locked" icon, e.g.
It's great now that minimalistic design is in style, but in a year when that fad has passed and my designer wants color again, I'm going to have to completely rewrite my infrastructure back away from using icon fonts.
Nice write-up. As a developer who has a keen design eye, but prefers not to actually deal with Photoshop (particularly icons!), this approach has been a huge relief for me.
I know there are many out there, but if anyone is looking for a nice font-pack, I use pictos (http://pictos.cc/font/). That said, it's $50.
Now that got me thinking. Fonts are basically a vector format. But with one thing added: hinting, that allows beautiful rendering at low resolutions. Why is there no support for hinting in SVG ? I hear media queries are coming, will they solve this problem ?
Fonts have dosens of things added: Unicode to glyph mapping, horizontal writing metrics, vertical writing metrics, kerning, hinting, bitmap fallbacks for small sizes, metadata for aligning baselines and justification, grid-fitting and scan-conversion data, glyph substitutions (e.g. ligatures, old style numbers, contextual, chained), glyph positioning (e.g. diacritics, Arabic diagonal baseline, contextual positioning).
Hinting is probably the most complex feature. TrueType implements hinting as special instructions in an impressively complex stack-based drawing language. SVG fonts are already bloated, and adding hinting may have been a step too far, or perhaps it was because at the time some of TrueType's hinting instructions were patented.
What are the benefits of using an icon font compared to just using svg icons? As far as I can tell, the only thing that a font can do better is get served in a single http request. I'd love to know what other differences are.
I'm not entirely sold on icon fonts. They look good at large sizes, but as they get smaller they become blurry. I'll stick to creating pixel perfect icons at different sizes.
I'll agree that the sort of pixel perfection you're after at smaller sizes isn't quite there yet (although well-hinted icon fonts are getting pretty close).
However, I think the advantages of icon fonts (packaged as a single file, automatically scalable, automatically retina-ready, colour-adaptive) are pretty compelling.
[1]: http://dev.w3.org/html5/spec-author-view/syntax.html#syntax-...