@font-face pitfalls and answers

Some useful tips to avoid certain @font-face pitfalls:

@font-face gotchas – Paul Irish [new window]


I have copied Paul’s post over here wholesale just in case his site ever goes down – Do check out his site though – there are always interesting posts to be found and I highly recommend it.

See also: Disasterman’s <pre>posterous – @font-face – The Complete Solution?

All content below here sould be considered © Paul Irish and his relevant sources, not me!



Over the past few months, I’ve collected a few worthwhile notes on @font-face that are worth reading over if you geek out about this stuff…

  • in Webkit (Chrome/Safari), applying font-weight:bold to faux-bold some @font-face’d text will not succeed. Same applies for font-style:italic. You can fix by adding the following to your @font-face declaration: (via doctypecrbug/31883crbug/35739webk.it/34147)
  • FF/Linux cannot serve webfonts from the file:// protocol. (Also, a tome on type quality with linux from Evan Martin)
  • TrueType format renders with a better quality than Opentype CFF. (sez Typekit) (fontsquirrel default)
  • In IE6-8, using createStyleSheet and then setting styleElem.styleSheet.cssText to a text value that includes a @font-face declaration going into will crash IE6-8. (src)
  • font-size-adjust (only supported in Firefox) normalizes x-height and may improve theFOUT.
  • text-transform doesn’t play well with @font-face in current implementations. (via snook & Gary Jones)
  • @font-face doesnt play nice with css transitions. (via ethan marcotte)
  • IE6 under High Security settings will pop a security dialog when a site tries to use @font-face. (via Wouter Bos)
  • There have been reports that when a font is segmented into multiple files, a css text-shadow can overlap in a weird way. (pics plz? 🙂
  • Aaron James Young dug into @font-face on obscure linux-only browsers.
  • If a @font-face declaration is within a media query @media screen { ..., it will fail in Firefox. (Thx Ben Kulbertis) http://bugzil.la/567573
  • Hosting the fonts on a different domain? Firefox requires some extra effort; you’ll need to add the Access-Control-Allow-Origin header, whitelisting the domain you’re pulling the asset from. Example .htaccess config here. Alternatively, you can use the base64 encoding in CSS (create it with the fontsquirrel generator) to avoid setting headers. details here
  • If you’re using @font-face will fillText() with <canvas>, then you might notice fillText NEEDS the font resource to load completely before you use it. And that’s up to you to manage. crbug.com/32879
  • SVG Fonts – Currently SVG is the only way to get webfonts working on iPhone and iPad. It is the most rudimentary format for fonts on the web.
    • SVG Fonts lack kerning and other complementary information
    • SVGz is a format that bakes compression right in and will save you bandwidth overhead. But you’ll need to add this to to your .htaccess for this benefit. AddType image/svg+xml svg svgz AddEncoding gzip svgz (via @fontsquirrel)
    • SVG fonts don’t work with a cache manifest. Due to the manifest treating # as comments and Mobile Safari requiring the font ID reference in the URL. [Unverified] (viaTristan Dunn)
    • Using text-overflow: ellipsis; turned the contents into only “…” and nothing else. (viaTristan Dunn)
    • Letter-spacing css doesnt appear to work with SVG fonts.
  • IIS Needs some custom mimetype configuration for serving webfonts. To enable, go to: Default Web Site > Properties > HTTP Headers > File Types > New Type…
    • .otf : font/otf
    • .svg : image/svg+xml

    (thx ProtectedVoid & Tom Nelson) — Test page

@font-face links that might have sneaked past you

And.. regarding @font-face syntax

I now recommend the bulletproof smiley variation over the original bulletproof syntax.

From the bulletproof post:

Yes, it’s a smiley face. The OpenType spec indicates any two-byte unicode characters won’t work in a font name on Mac at all, so that lessens the likelihood that someone actually released a font with such a name.

There are a few reasons why smiley is a better solution:

  • Webkit+Font Management software can mess up local references, like turning glyphs into A blocks.  (crbug.com/33173)
  • On OS X, Font Management software may alter system settings to show a dialog when trying to access a local() font that’s accessible outside of Library/Fonts. More detail on my bulletproof post. (crbug.com/29729) Font Explorer X is also known to mess up other stuff in Firefox: bugzil.la/531771
  • Although it’s unlikely, you could reference a local() font which is completely different than what you think it is. (Typophile post on different fonts, same name) At the very least its a risk, and you’re ceding control of the type to both the browser and host machine. This risk may not be worth the benefit of avoiding the font download.

These are all pretty edge case issues, but it’s worth considering. FontSquirrel has already made the smiley syntax the new default in the Generator, and you should use it going forward as well.

Take a look at some of my other (recently updated) webfont stuff:




Leave a Reply

Your e-mail address will not be published. Required fields are marked *