Here’s an annoying little bug that manifests when you try to set a CSS font-variant property (say, small-caps) with a font that doesn’t provide the requested variant. For instance, here is some text in League Gothic, pulled in via @font-face:
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.
Tags: browsers, CSS, font-face, typography, webfonts