greenideas

If you pay even a lit­tle atten­tion to emerg­ing trends in Web Stan­dards, you’re no doubt famil­iar with the explo­sion in inter­est in the CSS @font-face prop­erty. This prop­erty goes back to CSS2, and has been sup­ported in IE as far back as 5.5, but @font-face sup­port is being added at a rapid pace to other browsers, hence the recent surge of interest.

As some­one who spends his days devel­op­ing for mobile plat­forms, I wanted to check on how @font-face sup­port was pro­gress­ing in mobile browsers. Read on to see what I found out.

Method­ol­ogy

I put together a test page I used to check the extent of @font-face support.

I made test ele­ments and sep­a­rate font fam­i­lies for each font for­mat being tested (e.g. there’s a font fam­ily called “Chunk­Five SVG” that will only be applied to the span#SVG test ele­ment. View source on the sam­ple page for more details). I checked for @font-face sup­port with three cri­te­ria (two automated):

1. Ask each test ele­ment what font-family it thinks it is being ren­dered with. This is done via the window.getComputedStyle() method (and why I’m stick­ing with test­ing W3C com­pli­ant browsers at the moment). If all goes well, the return value should be some vari­ant of ChunkFive.
2. Check to see if the ren­dered text is wider than text ren­dered in the browser’s default font. For the test to pass, it has to be wider, since there are font size bugs in Mobile Safari (see below).
3. Eye­ball it. In some cases, the cri­te­ria above aren’t met, so the @font-face imple­men­ta­tion is incor­rect, but it’s close enough to be saved with some extra TLC.

I also included a test case based on Paul Irish’s Bul­let­proof @font-face syn­tax as a bit of a san­ity check and for the sake of hav­ing a less con­trived exam­ple. Lastly, I threw in sam­ples of Cufon and sIFR text, just for comparison.

All that said, here’s what I came up with.

Results

Mobile Safari 3.0

Sup­port for @font-face in Mobile Safari is cur­rently bro­ken in sev­eral frus­trat­ing ways:

1. Cer­tain for­mats (e.g. TTF & OTF), when applied, falsely report that they have been suc­cess­fully applied. That is, if you check the value of font-family from get­Com­put­ed­Style() on that ele­ment, it will return the @font-face value, even though it doesn’t ren­der as such. (Update 11/13: As Paul Irish cor­rectly pointed out in the com­ments to this post, Opera is actu­ally the only browser that returns the font that’s actu­ally used when getComputedStyle() is called.)
2. What’s worse, is that when this sit­u­a­tion occurs, if no fall­back font-family is spec­i­fied, the text will ren­der with the browser’s default font-family (as you’d expect), but it does so at less than the default font size. For­tu­nately, if you spec­ify a fall­back value in the font-family dec­la­ra­tion, it will ren­der the fall­back type­face at the cor­rect size, so always remem­ber to pick a degra­da­tion path for your fonts.
3. Another issue with text size arises if you use the SVG for­mat to get around the lack of sup­port for other for­mats on the iPhone. While you can indeed use SVG fonts in your font-face rules on the iPhone, text ren­dered in SVG fonts will ren­der at smaller than expected sizes. So if you opt for this strat­egy, just plan for this con­se­quence, and cor­rect the font sizes accord­ingly. Desk­top browsers that sup­port SVG fonts (Safari & Chrome) don’t exhibit this bug, so you need to tar­get this font-size fix to mobile browsers. You can eas­ily han­dle this case with a @media query in your stylesheet. Users of the Bul­let­proof Syn­tax will see this bug, since it will fall through to SVG on Mobile Safari.
   SVG fonts on Mobile Safari ren­der too small out of the box.
4. Another (pos­si­bly more aca­d­e­mic) issue is that call­ing getComputedStyle() on text ren­dered with an SVG font will not return the font-family value in your @font-face dec­la­ra­tion, even though it ren­ders with that font fam­ily. This could prove trou­ble­some if you’re using Javascript to test the suc­cess of your font rendering.

So if you need to use @font-face on Mobile Safari today, you should be sure to include an SVG ver­sion in your @font-face dec­la­ra­tion, and you should patch any text size bugs with a @media query. (If you’re not famil­iar with @media queries, you should read up on them.)

Inci­den­tally, Opera 10 on the desk­top also shows a slight vari­a­tion in font-size when using SVG fonts as well. How­ever, since it sup­ports True­Type and Open­Type for­mats, this shouldn’t cause any par­tic­u­lar issues if you’re using the bul­let­proof syn­tax (that’s why it’s bul­let­proof, yo).

Android 2.0 SDK

Short and not so sweet: There is no sup­port in the Android 2.0 SDK for any web­font for­mat. If you’re tar­get­ing Android, use Cufon.

Palm WebOS

Like Android, there is cur­rently no sup­port what­so­ever for @font-face in WebOS. Addi­tion­ally, in my (not at all exten­sive) tests, Cufon didn’t even appear to work at all (as in no text was rendered).

Sum­mary

In short, if you want your mobile site to join the Nice Web Type band­wagon, you have a lit­tle more work to do than for your desk­top site. Of all of the mod­ern WebKit-based mobile browsers, only Mobile Safari pro­vides any kind of @font-face sup­port. And even that sup­port is buggy and incom­plete. How­ever, if you are aware of these lim­i­ta­tions ahead of time (which you ought to be by this point in the post), you have a cou­ple of tricks in your back pocket to keep things run­ning smoothly.

What’s Next?

In the next lit­tle while, I’ll extend these tests to cover IE on WinMo and also do a sim­i­lar write-up for @font-face sup­port in desk­top browsers and tab­u­late all of the results in a lit­tle more for­mal manner.

Update: In case any­one wants to take a look under the hood of these tests with­out jump­ing through hoops in Fire­bug or View Source, the test code is up on Github.

Tags: CSS, font-face, typography, web standards, webfonts