{"id":14,"date":"2011-07-20T22:16:41","date_gmt":"2011-07-21T03:16:41","guid":{"rendered":"http:\/\/cbateman.com\/blogtest\/?p=14"},"modified":"2014-10-09T22:38:15","modified_gmt":"2014-10-10T03:38:15","slug":"font-face-awesomeness","status":"publish","type":"post","link":"https:\/\/cbateman.com\/blog\/font-face-awesomeness\/","title":{"rendered":"Font-Face Awesomeness"},"content":{"rendered":"

I still see\u00a0Cufon<\/a>\u00a0used pretty frequently (which surprises me), and even worse, there must be people still\u00a0trying to use sIFR<\/a>, because they tweeted this<\/a> a couple weeks ago:

\r\n

To whomever is still reading this, it’s 2011. Have a look at\u00a0@typekit\u00a0or\u00a0@fontdeck\u00a0or the likes, sIFR has gone unsupported for years.<\/p><\/blockquote>\r\n\r\n

Fortunately, we now have @font-face<\/a> to put almost any font on a web page. There are two basic ways to accomplish this: 1. Serve your own font files from your own server, or 2. Use a service like TypeKit <\/a>or Google Web Fonts<\/a>.<\/p>\r\n\r\n

Typekit has gotten pretty popular, but I’ve been pretty skeptical about those kind of services – why not just buy the fonts you need and serve them yourself? You don’t have to pay recurring costs, you don’t have to worry about exceeding pageview limits, you don’t have to worry about the service going down, and you can use as many fonts on as many sites as you like.<\/p>\r\n\r\n

When I built this site, I included five embedded fonts (mostly variants of one typeface). I was feeling pretty good about it until I took a look at the ‘Net’ tab in Firebug. My five fonts were about 90KB spread across five HTTP requests. Not fantastic – especially for mobile devices and other slow connections. And this is where Typekit and Google have come up with something that might<\/em>\u00a0be worth paying for.<\/p>\r\n\r\n

A neat CSS trick is that you can embed files right within the style sheet wherever you have a url property, like this:<\/p>\r\n

background-image:url(data:image\/png;base64,iVBORw0KGgoAAAANSUhEUgAAADIA...);<\/pre>\r\n\r\n
You can do this with fonts as well – which means that I can encode all five of my fonts and stick them into one style sheet – removing five HTTP requests. Awesome!<\/p>\r\n\r\n
But unfortunately, it’s a bit more complicated than that.<\/p>\r\n\r\n
If you want your fonts to work in most browsers and in older versions of iOS, you need to include four different types of font files (like so<\/a>), and the browser will download the first compatible font file. If I include all four versions encoded into in a single style sheet – I’m going to quadruple the size of the style sheet. Less HTTP requests, but much more data. Bummer.<\/p>\r\n\r\n
What Typekit and Google Web Fonts do is dynamically send each browser only<\/em> the compatible file type for that browser. Pretty cool. No matter how many fonts you have, they’re downloaded in a single, optimized style sheet.<\/p>\r\n\r\n
It would be interesting to try to set up something like this, but as far as I know, there’s no straightforward way to determine font compatibility in JavaScript (though I’m sure you could hack up something) – so you’d have to check the user agent. And that doesn’t sound like tons<\/em> of fun.<\/p>\r\n\r\n
On the bright side, WOFF<\/a> is gaining widespread support<\/a>: IE9+, FF 3.6+, Chrome, Safari 5.1+, Opera 11.1+, and iOS 5+.  So if you can do with supporting just those browsers – encode your WOFF files into a single style sheet and rock on.<\/p>\r\n\r\n