It’s time for a CSS3 @font-face browser support table. One that documents specifically how browsers act when either the whole font family is specified (regular, italic, bold, bold-italic & small-caps) or only the regular version of the font is specified. The test-case that this based on uses the ideal, easiest (laziest) implementation and can be found on its own page here.
Here’s the results of how current browsers render the test case, compared to the reference rendering.
Can the browser pick up the style natively?
| Firefox 3.6 | Safari 4 | Chrome 5 | Opera 10.5a | |
|---|---|---|---|---|
| Regular (Normal) | Yes | Yes | Yes | Yes |
| Italic | Yes | Yes | Yes | Yes |
| Bold | Yes | Yes | Yes | Yes |
| Bold-Italic | Yes | Yes | Yes | Yes |
| Small-Caps | Emulates | Fallback system-font | Fallback system-font | Emulates |
| Extras? | Ligatures! | – | – | Ligatures! |
Can the browser emulate from the regular version?
| Firefox 3.6 | Safari 4 | Chrome 5 | Opera 10.5a | |
|---|---|---|---|---|
| Regular (Normal) | (implied) | (implied) | (implied) | (implied) |
| Italic | Yes | Fallback to regular-style | Fallback to regular-style | Fallback to regular-style |
| Bold | Yes | Fallback to regular-style | Fallback to regular-style | Fallback to regular-style |
| Bold-Italic | Yes | Fallback to regular-style | Fallback to regular-style | Fallback to regular-style |
| Small-Caps | Yes | Fallback system-font | Fallback system-font | Yes |
| Extras? | Ligatures! | – | – | Ligatures! |
The most up to date support table, with pretty colours, can always be found on its own page alongside the test case. It also has more notes on ligatures and small-caps support.
Why is falling back to regular style so bad?
It makes sentences full of expression look like sentences full of expression. Thus removing part of the typographical elements of a text, whereas @font-face is meant to embellish it typographically.
So what does this mean we should do?
Browser developers:
- Please work on emulating bold, italic, bold-italic, etc. when they’re not present. Browsers already do this for system-fonts, which means web developers expect this to work. Falling back to the regular style (i.e. font-style:normal) is horrible as you lose all styling.
- Also give some thought to picking up “font-variant:small-caps;” in your @font-face code. It’s the only way to ensure proper fall-back. Emulating, like Firefox & Opera do, is a step forward, but it’d be a pity to stop there.
- If HTML 5 has taught us anything, it’s that browsers should be more bulletproof, not web designer’s code. Also: asking web developers to specify as little as possible is better.
Web designers:
- Using @font-face when you only have the regular version of a font at your disposal is not a good idea. Especially for body text.
- If you use small-caps text, chances are visitors will see the fallback system-font. So make sure you specify a system-font that matches your @font-face font nicely when rendered as small-caps. (The test-case uses an especially jarring one on purpose.)
- Use a (less lazy, less practical) more bulletproof way of specifying your @font-face fonts is recommended (alas) for now.
3 replies on “CSS3 @font-face browser support table”
It’s really time for CSS3 and @font-face is one of the most interesting features. Thx for sharing this browser-support-overview!
James,
I responded to your comment on Readable Web.
Will be looking at this more closely. And thanks for it, too.
Helpful.
BTW – using @font-face when you only have the regular version of a font is perfectly fine. I take issue with characterizing it as “not a good idea”. Too sweeping.
If someone is using a font for headings, style variations are seldom an issue. I just fear that people will get the wrong idea and shy away from @font-face entirely.
I do agree that body text is a special case and when someone experiments with it and has only the regular member of the font family, they’ll find out pretty quick what’s up.
Rich
It should be fine, but it isn’t due to the silly fallback browsers do.
Headings are often bold. You see a lot of examples popping up with people simply declaring the BoldVersion.ttf directly. Which is silly, as it’ll fallback to the regular version on non-font-face supporting browsers.
The point is not to shy people away from @font-face, but rather to get browser support to a good enough level so that web developers don’t have to worry about backwards compatibility.