@font-face enhanced designs, remotely hosted fonts, and you

A little background

I’ve always thought of the stuff on this blog as a kind of casual conversation between friends. You know, the kind of stuff that would start out on the back of a napkin, but would stick with you and shape the way you think about things. I picked this particular theme because it reminded me of a bunch of notes, and the relatively narrow column layout makes reading comfortable. I had some ideas about how to further extend the metaphor, but I knew that I wanted to change the fonts up a bit. It just felt too stuffy in here.

Common web fonts weren’t going to cut it, so I decided that I would spend the time and learn about the @font-face directive. If you want to try this, the first thing you should do is check out Paul Irish’s post on Bulletproof @font-face syntax. The syntax really does work everywhere.

And because I didn’t feel like spending a bunch of money on fonts, I headed over to Font Squirrel (p.s. Font Squirrel is totally awesome) to find a few that would suit my purposes:

  1. Give the blog a bit more of a personal feel
  2. Don’t make body content a chore to read

After a bunch of debate, I settled on Rabiohead for the headers and any special text on the page, and Colaborate for body text and navigation. The big selling points of these particular faces were:

  • The handwritten look of Rabiohead took some of the corporate/boring feel out of the headers and personalized them a bit
  • Colaborate was consistent enough to make reading pleasant, but still had a bit of a whimsical twist to it. Not your average sans-serif font.

Phew! Stuffiness eliminated (mostly).

The problem

Everything looked good in Chrome, Safari, and IE, and…WTF?! Busted in Firefox. I thought that my CSS must be invalid somehow. Nope. Then I thought that Firefox must not be downloading the font files for some reason, but Firebug quickly disproved that hypothesis. Google to the rescue!? Not really. It took me a while to find even a passing mention that these font imports in Firefox were restricted by cross-domain content loading rules. Aha!

Because I’m hosting this blog on Tumblr, I don’t have the option, as far as I know, to host the font files (at least not in my custom domain). Instead, I chose to drop them on my old hosting site and pull them in using a remote URL. Again, this works fine for Safari, Chrome, and IE. Only Firefox tries to protect you from the evils of font files from other domains (I know it tastes bad, but it’s for your own good!).

Now that I understood the problem, it was a bit easier to figure out my options. Once again, Paul Irish came to my aid with his discussion of @font-face gotchas.

There are two strategies:

  1. Add the Access-Control-Allow-Origin header, whitelisting the domain you’re pulling the asset from. Example.
  2. Base64 encode the entire font, and shove it right in the CSS file, and Geoff Evason has a good guide for that.

I chose the latter, because I didn’t feel like screwing around with .htaccess files on my hosted domain. And, viola! Base64 encoded font data worked like a charm, and showed up perfectly in all of the browsers I tested. I started poking around, and it appears that this problem impacts lots of hosted blogs that use a custom domain, on Tumblr and elsewhere.

Hope this helps anyone else out there who’s run into this but couldn’t find a solution.