League Gothic doesn’t have its own small caps variant. So what happens when you tell the browser to give you one anyway? Here it is with font-variant: small-caps applied as rendered in Firefox:

So far, so good. But here’s what you get when you add small caps to League Gothic in Webkit:

Whoops! Webkit-based browsers (I tested this in Safari, Webkit Nightly, and Chrome for OSX), when they don’t find the specified variant in the font itself, just go to the next font in the stack. In this case, it’s the browser’s default font.

So which behavior is correct? The CSS2 spec essentially left it up to implementors to decide whether or not they would dynamically scale the font to implement small caps. CSS3 removes the ambiguity:

If a genuine small-caps font is not available, user agents should simulate a small-caps font, for example by taking a normal font and replacing the lowercase letters by scaled uppercase characters. (CSS fonts module level 3)

Although a typographic purist might take issue with this behavior (Bringhurst rails against the practice of “rolling your own” variants by dynamically scaling the existing face), this is what the spec says browsers are supposed to do. And in fact, this is what Firefox does. Webkit, on the other hand, checks each font in the stack in order until it finds one that supplies the desired variant. As in the example above, if there’s nothing else in the stack, it will fall back on the browser’s default font.

Unfortunately, there aren’t really any workarounds for this bug. But it should serve to remind you yet again that it’s super-important to put a good deal of thought into your font stack. Always try to build a stack where all of the fonts are as similar as possible, so when something like this happens, your design doesn’t break too badly.

For reference, or if you’d like to see how your browser of choice handles these cases, here are some test cases together on a separate page.

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.