4 ms·

The Font-Face Firefox Fiasco

16 points by bryckbost 14y ago

Zirro 14y ago
"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 14y ago
  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 14y ago
    Plus "fiasco" helps with the alliteration.
    - vampirechicken 14y ago
      As would any number of other f-words that also were not correct in context.
  - leephillips 14y ago
    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/ http://lee-phillips.org/google-chromeBadKerning/
- JoshTriplett 14y ago
  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.
duopixel 14y ago
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/ http://paulirish.com/2009/fighting-the-font-face-fout/
BSeward 14y ago
Sass' Compass framework has a helper to automatically generate inline data URIs. http://compass-style.org/reference/compass/helpers/inline-data/#inline-font-files 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.
andrewcooke 14y ago
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 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 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 14y ago
  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 14y ago
    thanks!
FuzzyDunlop 14y ago
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.

16 points by bryckbost 14y ago

Zirro 14y ago

"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 14y ago
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 14y ago
  Plus "fiasco" helps with the alliteration.
  - vampirechicken 14y ago
    As would any number of other f-words that also were not correct in context.
- leephillips 14y ago
  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/ http://lee-phillips.org/google-chromeBadKerning/
JoshTriplett 14y ago
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.

duopixel 14y ago

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/ http://paulirish.com/2009/fighting-the-font-face-fout/

BSeward 14y ago

Sass' Compass framework has a helper to automatically generate inline data URIs. http://compass-style.org/reference/compass/helpers/inline-data/#inline-font-files 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.

andrewcooke 14y ago

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 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 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 14y ago
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 14y ago
  thanks!

FuzzyDunlop 14y ago

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.