
The Font-Face Firefox Fiasco - bryckbost
http://collectiveidea.com/blog/archives/2012/07/05/the-font-face-firefox-fiasco/
======
Zirro
"It seems Firefox is the only browser to adhere to the specification in this
regard."

I fail to see how being the only browser to honour the specification is
anywhere near being a "fiasco" (which is defined as "a thing that is a
complete failure"). There's most likely a reason for the way the specification
is designed, and in this case Firefox should get credit for being the only
browser doing it correctly.

~~~
bryckbost
True. The fiasco is more or less around the issue of discovering the root
cause of why my fonts weren't displaying properly in Firefox, when they did in
webkit.

~~~
danielmorrison
Plus "fiasco" helps with the alliteration.

~~~
vampirechicken
As would any number of other f-words that also were not correct in context.

------
andrewcooke
so how do google web fonts work? i just started to use them - all i do is
include a

<link href="<http://fonts.googleapis.com/css?family=Muli:300,400>
rel="stylesheet" type="text/css">

and everything "just works". even in firefox. as far as i know, the fonts are
being pulled in from google. all i did was include the above link in my pages,
but my site is served from my isp (<http://www.acooke.org> if you're curious).

that's fonts, in firefox, from a non-origin location. i'm obviously not
understanding something (as i said, this is the first time i've used separate
fonts). what am i missing? thanks...

~~~
JoshTriplett
Loading fonts from another domain requires that domain to explicitly whitelist
your use as acceptable, using a CORS (cross-origin resource sharing) policy.

    
    
        ~$ GET 'http://fonts.googleapis.com/css?family=Muli:300,400' | grep src:
          src: local('Muli Light'), local('Muli-Light'), url(http://themes.googleusercontent.com/static/fonts/muli/v4/zR-6QGMCFX5j-6nbH_HpIQ.ttf) format('truetype');
          src: local('Muli'), url(http://themes.googleusercontent.com/static/fonts/muli/v4/BfQP1MR3mJNaumtWa4Tizg.ttf) format('truetype');
        ~$ HEAD http://themes.googleusercontent.com/static/fonts/muli/v4/BfQP1MR3mJNaumtWa4Tizg.ttf | grep '^Access-Control'
        Access-Control-Allow-Origin: *
    

Google uses "Access-Control-Allow-Origin: *", but another site could easily
provide customer-specific URLs and use "Access-Control-Allow-Origin: paying-
customer.example.com". This restriction on @font-face exists for exactly that
reason, which explains why browsers other than Firefox have intentionally not
implemented it.

I wonder what it would take to get Mozilla to reconsider that decision? This
doesn't seem like a point worth diverging from other browsers on; in this
case, the other browsers got it right and Firefox got it wrong.

~~~
andrewcooke
thanks!

------
BSeward
Sass' Compass framework has a helper to automatically generate inline data
URIs. [http://compass-style.org/reference/compass/helpers/inline-
da...](http://compass-style.org/reference/compass/helpers/inline-data/#inline-
font-files)

This is handy for media that will change--inlined images and such. Manually
updating encodes is an easy step to forget.

------
duopixel
It never occurred to me that you could include an encoded font in the
stylesheet. Perhaps this not only eliminates a request, but it fixes Flash of
Unstyled Text (FOUT) for browsers that support data-uri's.

<http://paulirish.com/2009/fighting-the-font-face-fout/>

------
FuzzyDunlop
As an aside, I like how they base64 encode the font the Unix way. It's one of
those things you'd generally expect to be a plug for an API.

