If you pay even a little attention to emerging trends in Web Standards, you’re no doubt familiar with the explosion in interest in the CSS @font-face property. This property goes back to CSS2, and has been supported in IE as far back as 5.5, but @font-face support is being added at a rapid pace to other browsers, hence the recent surge of interest.

As someone who spends his days developing for mobile platforms, I wanted to check on how @font-face support was progressing in mobile browsers. Read on to see what I found out.

Methodology

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

I made test elements and separate font families for each font format being tested (e.g. there’s a font family called “ChunkFive SVG” that will only be applied to the span#SVG test element. View source on the sample page for more details). I checked for @font-face support with three criteria (two automated):

1. Ask each test element what font-family it thinks it is being rendered with. This is done via the window.getComputedStyle() method (and why I’m sticking with testing W3C compliant browsers at the moment). If all goes well, the return value should be some variant of ChunkFive.
2. Check to see if the rendered text is wider than text rendered 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. Eyeball it. In some cases, the criteria above aren’t met, so the @font-face implementation is incorrect, but it’s close enough to be saved with some extra TLC.

I also included a test case based on Paul Irish’s Bulletproof @font-face syntax as a bit of a sanity check and for the sake of having a less contrived example. Lastly, I threw in samples of Cufon and sIFR text, just for comparison.

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

Results

Mobile Safari 3.0

Support for @font-face in Mobile Safari is currently broken in several frustrating ways:

1. Certain formats (e.g. TTF & OTF), when applied, falsely report that they have been successfully applied. That is, if you check the value of font-family from getComputedStyle() on that element, it will return the @font-face value, even though it doesn’t render as such. (Update 11/13: As Paul Irish correctly pointed out in the comments to this post, Opera is actually the only browser that returns the font that’s actually used when getComputedStyle() is called.)
2. What’s worse, is that when this situation occurs, if no fallback font-family is specified, the text will render with the browser’s default font-family (as you’d expect), but it does so at less than the default font size. Fortunately, if you specify a fallback value in the font-family declaration, it will render the fallback typeface at the correct size, so always remember to pick a degradation path for your fonts.
3. Another issue with text size arises if you use the SVG format to get around the lack of support for other formats on the iPhone. While you can indeed use SVG fonts in your font-face rules on the iPhone, text rendered in SVG fonts will render at smaller than expected sizes. So if you opt for this strategy, just plan for this consequence, and correct the font sizes accordingly. Desktop browsers that support SVG fonts (Safari & Chrome) don’t exhibit this bug, so you need to target this font-size fix to mobile browsers. You can easily handle this case with a @media query in your stylesheet. Users of the Bulletproof Syntax will see this bug, since it will fall through to SVG on Mobile Safari.
   SVG fonts on Mobile Safari render too small out of the box.
4. Another (possibly more academic) issue is that calling getComputedStyle() on text rendered with an SVG font will not return the font-family value in your @font-face declaration, even though it renders with that font family. This could prove troublesome if you’re using Javascript to test the success of your font rendering.

So if you need to use @font-face on Mobile Safari today, you should be sure to include an SVG version in your @font-face declaration, and you should patch any text size bugs with a @media query. (If you’re not familiar with @media queries, you should read up on them.)

Incidentally, Opera 10 on the desktop also shows a slight variation in font-size when using SVG fonts as well. However, since it supports TrueType and OpenType formats, this shouldn’t cause any particular issues if you’re using the bulletproof syntax (that’s why it’s bulletproof, yo).

Android 2.0 SDK

Short and not so sweet: There is no support in the Android 2.0 SDK for any webfont format. If you’re targeting Android, use Cufon.

Palm WebOS

Like Android, there is currently no support whatsoever for @font-face in WebOS. Additionally, in my (not at all extensive) tests, Cufon didn’t even appear to work at all (as in no text was rendered).

Summary

In short, if you want your mobile site to join the Nice Web Type bandwagon, you have a little more work to do than for your desktop site. Of all of the modern WebKit-based mobile browsers, only Mobile Safari provides any kind of @font-face support. And even that support is buggy and incomplete. However, if you are aware of these limitations ahead of time (which you ought to be by this point in the post), you have a couple of tricks in your back pocket to keep things running smoothly.

What’s Next?

In the next little while, I’ll extend these tests to cover IE on WinMo and also do a similar write-up for @font-face support in desktop browsers and tabulate all of the results in a little more formal manner.

Update: In case anyone wants to take a look under the hood of these tests without jumping through hoops in Firebug or View Source, the test code is up on Github.