The Font-Face Firefox Fiasco | Hacker News Reader

The Font-Face Firefox Fiasco

collectiveidea.com

16 pointsbryckbost12 comments

"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.

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.

Plus "fiasco" helps with the alliteration.

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

Depends which webkit browser you're using. Chrome has weird problems[1] in displaying these fonts, for example.

[1]http://lee-phillips.org/google-chromeBadKerning/

Specifications can have bugs or deficiencies, and in those cases diverging from the specification can provide a net win. Also note that in this case the specification considers the cross-origin restrictions optional, not mandatory.

In this case, prohibiting the loading of fonts from other domains (unlike img, video, audio, CSS, script, etc) seems both unnecessary and harmful.

As I understand it, that bit of the specification exists for the sole purpose of mollifying large commercial font foundries, who consider themselves the only source of usable fonts, and who consider this particular point an existential threat.

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

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...

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.

thanks!

Sass' Compass framework has a helper to automatically generate inline data URIs. http://compass-style.org/reference/compass/helpers/inline-da...

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

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/

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.

Reply on news.ycombinator.com