The @Font-Face Firefox Fiasco
In Firefox, web fonts must be on the same domain as the page using them unless you’ve updated HTTP access controls to allow for cross-origin resource sharing. It seems Firefox is the only browser to adhere to the specification in this regard.
So, you’re building out an awesome Tumblr theme and notice fonts aren’t rendering in Firefox because they’re hosted on a different domain. Changing the access controls is hard and can’t be done on sites like Tumblr. What do you do?
Base64 encode them.
Yes, it will inflate the size of the CSS. But you’re eliminating a request. A tradeoff I can live with. Here’s how to do it in two easy steps.
-
Base64 encode the font file
cat /Volumes/Entypo/@font-face/entypo-webfont.ttf openssl enc -base64 tr -d ‘\n’ pbcopy -
Paste the data into the stylesheet
@font-face {
…
src: url(‘data:font/opentype;base64,« BASE64 ENCODED DATA HERE »’) format(‘truetype’);
…
}
Further reading
- Data URIs on css-tricks.com
- “
font-face":https://developer.mozilla.org/en/CSS/
font-face/ on Mozilla Developer Network
Comments
OpenSSL? Oy! What’s wrong with /usr/bin/base64?
@anon: absolutely nothing, I just knew about openssl. Thanks for the tip though
I believe Firefox is not the only browser to do this — IE9 and IE10 also impose the same-origin restriction.
Ha, was just dealing with this today.
Two things:
1) You can do this automatically in the Rails asset pipeline by calling asset_data_uri. Makes things nice and clean from a dev perspective.
2) IE 7 & 8 (not 9) will choke completely on the @font-face (and maybe the whole CSS file)–they have a 32k limit on data urls. Splitting out a separate IE fonts CSS gets around this.
@E.J.: Whoa, I had no idea about asset_data_uri. Thanks for pointing that out!
I can live with the trade off too. thanks for a great post
Oh thank you so much, I’d despaired of ever finding a solution to this problem. I can’t tell you how relieved I am to finally find a fix for this, but thank you for taking the time to write this.
THANK YOU SO MUCH! I’m working with a CMS that publishes sites to a staging server, then transfers to the live server. My fonts were stored on the live server, and I couldn’t figure out why things wouldn’t display correctly on the staging server. Your opening paragraph just solved all my problems. Big DUH. Thanks!