Return to Candy by James homepage

CSS3 @font-face browser support table 2012

It’s time to update the CSS3 @font-face browser sup­port table. It doc­u­ments spe­cific­ally how browsers act when either the whole font fam­ily is spe­cified (reg­u­lar, italic, bold, bold-italic & small-caps) or only the reg­u­lar ver­sion of the font is spe­cified. The test-case that this based on uses the ideal, easi­est (lazi­est) imple­ment­a­tion and can be found on its own page here.

This is a robust­ness test. What hap­pens if some font vari­ants don’t load? What if there’s only one vari­ant to begin with? Will inform­a­tion be lost? Those ques­tions can be answered with this test.

Here’s the res­ults of how browsers in 2012 render the test case, com­pared to the ref­er­ence ren­der­ing. Mobile browsers have been added too.

Can the browser pick up the style natively?

Firefox 14 Safari 5 Chrome 19 Opera 12 IE 10 cp
Normal (reg­u­lar) Yes Yes Yes Yes Yes
Italic Yes Yes Yes Yes Emulates
Bold Yes Yes Yes Yes Emulates
Bold-Italic Yes Yes Yes Yes Emulates
Small-Caps (reg­u­lar) Emulates Emulates Emulates Emulates Emulates
Small-Caps Italic Emulates Fallback to reg­u­lar Small-Caps Emulates Emulates [3] Emulates
Small-Caps Bold Emulates Fallback to reg­u­lar Small-Caps Emulates Emulates [3] Emulates
Small-Caps Bold-Italic Emulates Fallback to reg­u­lar Small-Caps Emulates Emulates [3] Emulates
Extras? Ligatures![1] - - Ligatures![1] Ligatures![1]

How are mobile browsers with nat­ive variants?

iOS 5.1.1 Opera Mobile 12 Google Nexus One (Android 2.1) Samsung Galaxy Tab (Android 2.2) HTC Evo 3D (Android 2.3)
Normal (reg­u­lar) Yes Yes Yes Yes Yes
Italic Yes Yes Yes Yes Yes
Bold Yes Yes Yes Yes Yes
Bold-Italic Yes Yes Yes Yes Yes
Small-Caps (reg­u­lar) Emulates Emulates Emulates Emulates Emulates
Small-Caps Italic Fallback to reg­u­lar Small-Caps Emulates Emulates Emulates Emulates
Small-Caps Bold Fallback to reg­u­lar Small-Caps Emulates Emulates Emulates Emulates
Small-Caps Bold-Italic Fallback to reg­u­lar Small-Caps Emulates Emulates Emulates Emulates

Conclusion: Many browsers (Chrome, Opera) have made tre­mend­ous pro­gress. Only Safari is still lack­ing in its imple­ment­a­tion, in the edge case where Small-Caps text has added emphasis. IE 10 goes the curi­ous route of emu­lat­ing all vari­ants and styles from the reg­u­lar version.

Can the browser emu­late from the reg­u­lar version?

Firefox 14 Safari 5 Chrome 19 Opera 12 IE 10 cp
Normal (Regular) (implied) (implied) (implied) (implied) (implied)
Italic Yes Fallback to regular-style Yes Yes Yes
Bold Yes Fallback to regular-style Yes Yes Yes
Bold-Italic Yes Fallback to regular-style Yes Yes Yes
Small-Caps (reg­u­lar) Yes Yes Yes Yes Yes
Small-Caps Italic Yes Fallback to reg­u­lar Small-Caps Yes Emulates [3] Yes
Small-Caps Bold Yes Fallback to reg­u­lar Small-Caps Yes Emulates [3] Yes
Small-Caps Bold-Italic Yes Fallback to reg­u­lar Small-Caps Yes Emulates [3] Yes
Extras? Ligatures![1+*] - - Ligatures![1+*] Ligatures![1+*]

Do mobile browsers emu­late properly?

iOS 5.1.1 Opera Mobile 12 Google Nexus One (Android 2.1) Samsung Galaxy Tab (Android 2.2) HTC Evo 3D (Android 2.3)
Normal (Regular) (implied) (implied) (implied) (implied) (implied)
Italic Fallback to regular-style Fallback to regular-style Yes Fallback to regular-style Fallback to reg­u­lar Small-Caps
Bold Fallback to regular-style Fallback to regular-style Yes Fallback to regular-style Fallback to reg­u­lar Small-Caps
Bold-Italic Fallback to regular-style Fallback to regular-style Yes Fallback to regular-style Fallback to reg­u­lar Small-Caps
Small-Caps (reg­u­lar) Yes Yes Yes Yes Yes
Small-Caps Italic Fallback to reg­u­lar Small-Caps Fallback to reg­u­lar Small-Caps Yes Fallback to reg­u­lar Small-Caps Fallback to reg­u­lar Small-Caps
Small-Caps Bold Fallback to reg­u­lar Small-Caps Fallback to reg­u­lar Small-Caps Yes Fallback to reg­u­lar Small-Caps Fallback to reg­u­lar Small-Caps
Small-Caps Bold-Italic Fallback to reg­u­lar Small-Caps Fallback to reg­u­lar Small-Caps Yes Fallback to reg­u­lar Small-Caps Fallback to reg­u­lar Small-Caps

Conclusion: Safari and most mobile browsers still fall back to reg­u­lar style. This means web developers can not use web fonts for body text if they have only one (reg­u­lar) vari­ant nat­ively avail­able to them.

The most up to date sup­port table, with pretty col­ours, can always be found on its own page along­side the test case. It also has more notes on lig­at­ures and small-caps support.

Why is fall­ing back to reg­u­lar style so bad?

It makes sen­tences full of expres­sion look like sen­tences full of expres­sion. It removes part of the typo­graph­ical ele­ments of a text, which is ironic, given that @font-face is meant to embel­lish it typo­graph­ic­ally. At its core, fall­ing back to reg­u­lar style removes information.

So what does this mean we should do?

Browser developers:

  • Safari devs: please work on emu­lat­ing bold, italic, bold-italic, etc. when they’re not present. Browsers do this already when it comes to system-fonts, which means web developers expect this to work.
  • Also give some thought to pick­ing up “font-variant:small-caps;” in your @font-face code. It’s the only way to ensure proper fall-back. Emulating, (like Firefox & Opera you all now do!) is a step for­ward, but it’d be a pity to stop there.
  • If HTML 5 has taught us any­thing, it’s that browsers should be more bul­let­proof, not web designer’s code. Also: ask­ing web developers to spe­cify as little as pos­sible is a better.

Web design­ers:

CSS3 @font-face browser support table 2010

Update: Have a look at the browser sup­port table for 2012 here.

It’s time for a CSS3 @font-face browser sup­port table. One that doc­u­ments spe­cific­ally how browsers act when either the whole font fam­ily is spe­cified (reg­u­lar, italic, bold, bold-italic & small-caps) or only the reg­u­lar ver­sion of the font is spe­cified. The test-case that this based on uses the ideal, easi­est (lazi­est) imple­ment­a­tion and can be found on its own page here.

Here’s the res­ults of how cur­rent browsers render the test case, com­pared to the ref­er­ence 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 emu­late from the reg­u­lar 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 sup­port table, with pretty col­ours, can always be found on its own page along­side the test case. It also has more notes on lig­at­ures and small-caps support.

Why is fall­ing back to reg­u­lar style so bad?

It makes sen­tences full of expres­sion look like sen­tences full of expres­sion. Thus remov­ing part of the typo­graph­ical ele­ments of a text, whereas @font-face is meant to embel­lish it typographically.

So what does this mean we should do?

Browser developers:

  • Please work on emu­lat­ing 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 reg­u­lar style (i.e. font-style:normal) is hor­rible as you lose all styling.
  • Also give some thought to pick­ing 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 for­ward, but it’d be a pity to stop there.
  • If HTML 5 has taught us any­thing, it’s that browsers should be more bul­let­proof, not web designer’s code. Also: ask­ing web developers to spe­cify as little as pos­sible is better.

Web design­ers:

  • Using @font-face when you only have the reg­u­lar ver­sion of a font at your dis­posal is not a good idea. Especially for body text.
  • If you use small-caps text, chances are vis­it­ors will see the fall­back system-font. So make sure you spe­cify a system-font that matches your @font-face font nicely when rendered as small-caps. (The test-case uses an espe­cially jar­ring one on purpose.)
  • Use a (less lazy, less prac­tical) more bul­let­proof way of spe­cify­ing your @font-face fonts is recom­men­ded (alas) for now.

Vertically centring in css (without hacks and multi-line enabled)

Chris Coyier over at css-tricks.com had a great example of a css conun­drum: how to centre, both ver­tic­ally and hori­zont­ally, mul­tiple lines of text. He some good code (using table-cell) but his code for IE relied on some (script)expressions which can have the unfor­tu­nate habbit of slow­ing down a page.

[update: to get a bit more back­ground on abso­lute & rel­at­ive pos­i­tion­ing, and how to cen­ter hori­zont­ally, read:  On Horizontal CSS Centering using Absolute Positioning or how Relative Positioning can rock your css.]

The reg­u­lar way of ver­tic­ally cent­ring in css has been doc­u­mented by Dušan Janovský back in 2004. It needs an extra div for its IE solu­tion, but it doesn’t require any expres­sions, only reg­u­lar (fast!) css. Because a div-tag is semantic­ally empty (like the span-tag), it doesn’t add any wrong semantic mean­ing (like a table-tag would).

The .area div isn’t stricly neces­sary, but it was in the ori­ginal prob­lem posed in the css-tricks.com art­icle. I have how­ever edited out the super­flu­ous back­ground declar­a­tion, as it doesn’t have any­thing to do with positioning.

I’ve updated the example to use con­di­tional com­ments instead of hacks. The html (in your page) becomes:

<div class="area" id="two">
<div class="bubble">
<div>
<p>Doing this may not be as easy or obvious as we would hope.</p>
</div>
</div>
</div>

The css (in your stylesheet) becomes:

.area {width:300px; height:300px; position:relative; float:left; }
.bubble {position:absolute; left:93px; top:21px; width:135px; height:84px; display:table; }
.bubble div {display:table-cell; vertical-align:middle; text-align:center;}

The IE spe­cific css (in your html-page) becomes:

<!--[if lt IE 8]>
<style>
.bubble div {position:absolute; top:50%;}
.bubble div p {position:relative; top:-50%}
</style>
<![endif]–>

Have a look at the demo to see what you should end up with. Questions welcome!

CSS3 Fonts: The ideal implementation

This series of art­icles is about the chal­lenges that arise when using @font-face. Font licens­ing is one (that many oth­ers have writ­ten about) and the file-size of included font-files is another, but this art­icle is about browser imple­ment­a­tion eccent­ri­cit­ies. I’ll start off by show­ing the ideal @font-face imple­ment­a­tion in this art­icle, before mov­ing on to show­ing cur­rent browser defi­cien­cies and the imple­ment­a­tion I settled on for includ­ing a full font-family which works in the here and now.

update: For an over­view of cur­rent browser sup­port for CSS3’s @font-face see the browser sup­port tables.

Ideally, design­ers would spe­cify the font-file they wanted to use for reg­u­lar text, and then one for each vari­ation they had at their dis­posal (so, one for Bold, Italic, Bold Italic, Small Caps, Light, Ultra Condensed, etc.) – all using the same font-family name, so that all vari­ations would be picked up auto­mat­ic­ally for body text, and, if @font-face isn’t sup­por­ted by the browser,  all text will still dis­play in the proper font-variant.

To do that, your css would look some­thing like this:

/* A font by Jos Buivenga (exljbris) -> www.exljbris.nl */
@font-face {font-family: "Fontin Sans";
src: url(fonts/Fontin_Sans_R_45b.otf) format("opentype");
}
@font-face {font-family: "Fontin Sans";
src: url(fonts/Fontin_Sans_B_45b.otf) format("opentype");
font-weight: bold;
}
@font-face {font-family: "Fontin Sans";
src: url(fonts/Fontin_Sans_I_45b.otf) format("opentype");
font-style: italic;
}
@font-face {font-family: "Fontin Sans";
src: url(fonts/Fontin_Sans_BI_45b.otf) format("opentype");
font-style: italic;
font-weight: bold;
}
@font-face {font-family: "Fontin Sans";
src: url(fonts/Fontin_Sans_SC_45b.otf) format("opentype");
font-variant: small-caps;
}

This would ensure proper fall-back in browsers that don’t sup­port @font-face (or only part of it) and com­pat­ib­il­ity with cur­rent stylesheets, mak­ing @font-face imple­ment­a­tion for design­ers plug-&-play.

The ideal @font-face ren­der­ing (on the left) and fall-back ren­der­ing (on the right) would look a little like this (notice the fi-ligature!):

ideal-fallback

You’ll have guessed by now that browsers haven’t reached this ideal imple­ment­a­tion yet. You can find the test-case and CSS3 @font-face browser sup­port tables here.

Information in this series was acquired while work­ing on the design and css for the site of Standards.next and sub­sequent tests after­wards. The Fontface used in this example is Fontin Sans by Exljbris (Jos Buivenga).

Bye bye liquid layouts!

Yes, I am pre­dict­ing the death of liquid lay­out of web pages. Not all mind you, some web apps will still be liquid, but for the rest of the web: liquid is dead. This is a nat­ural next step after declar­ing elastic lay­outs dead, so no sur­prises here.

There are three main ways to define your lay­out in web design: fixed, elastic & liquid. Having writ­ten about the dif­fer­ences between them before, I’ll suf­fice with stat­ing that fixed lay­outs are defined in “px” (pixels) and liquid ones in “%” (percentages).

Using a fixed lay­out means your web page is the same width irre­spect­ive of the view­ers’ screen width, like so:

Fixed layout.

Using a liquid lay­out how­ever, means your web page scales along with the view­ers’ screen width, like so:

Liquid layout.

Liquid lay­outs used to have an edge over pixel lay­outs in the sense that they increased use of the screen real estate, thus provid­ing more room if the viewer increased their text-size. Line-lengths are hard to con­trol with liquid lay­outs, because of vary­ing screen-sizes obvi­ously, but also when the viewer increases (just) the text-size. Jason Kottke pos­ted a good warn­ing about line-lengths in liquid lay­outs a while back:

Attention liquid design­ers: take a gander at this por­tion of an ancient Egyptian parch­ment on papyrus from the Louvre. Even the ancient Egyptians knew not to make columns of text too wide.

Now, how­ever, most browsers have adop­ted full-page zoom­ing over text-size zoom­ing. Most provide both, but full-page zoom­ing is the new default. Full-page zoom­ing gives users with a wider screen (for example) the chance to increase the size of text and images, while still pre­serving the ratios of fixed lay­out pages, like so:

Fixed design with full zoom.

As you can see, full-page zoom­ing means fixed lay­outs also provide increased use of screen real estate, but only when needed. In addi­tion fixed lay­outs keep line-lengths rel­at­ively stable, and are easy to work with as they are based on pixels, just like images, videos and other objects you may have on your web page.

Elastic, Liquid, Pixel: Explained.

In ‘mod­ern’ web design (as in, the last five years versus the five years before) there are three main ways to define your design.

Also called ‘fixed’, the first and most used method uses pixel meas­ure­ments to define the width (& height) of ele­ments on a page. The most obvi­ous advant­age to this method — and the reason it’s the easi­est to get your head around — is that you get pixel per­fect res­ults with it. Photos and other fixed ele­ments on your page will always fit, another huge advant­age. That’s also its down­fall how­ever, as it doesn’t increase in size as text scales, mak­ing the defin­ing of a good line-length quite difficult.

Which brings us to the next, most recent, method dubbed ‘elastic’. The crux of this method revolves around using ‘em’ to define (mainly) widths instead of ‘px’. You’ve already guessed of course that ‘px’ stands of pixel — but how is ‘em’ exactly defined? Well, an ‘em’ is the width a nor­mal ‘m’ takes up on the screen. This method has the advant­age of scal­ing along with the text. That means your line-length will always be exactly as you defined it, but, if an included pic­ture were to take up more width than the cur­rent line-length, it’d stick out.

Liquid has been going in and out of fash­ion for a couple of years now. It uses per­cent­ages (defined with ‘%’ in one’s code of course) to define the width of ele­ments. I think it was cre­ated with the inten­tion of not squan­der­ing pre­cious screen real estate, and while it does max­im­ise the use of the screen, it has sev­eral flaws. Given that screen sizes can vary a great deal, a designer can never be cer­tain the line-length is any­where near cor­rect and whether or not pho­tos actu­ally fit (push­ing them­selves off the screen, or worse, push­ing the design off the screen!).

In my next art­icle (not neces­sar­ily the next post!) I’ll talk more about hand­ling the down­sides of the meth­ods and how a mix of them is often the most effect­ive (and laden with browser flow errors — yikes!).

CSS selectors explained properly

Looking for a good and simple explan­a­tion of the cur­rently usable (and a few more) CSS select­ors? Roger Johansson has taken the time to com­pile them all into a 3 part art­icle. I can thor­oughly recom­mend it to people want­ing a nice over­view of what tools are avail­able to them in Cascading Style Sheets or just want to know what the heck “.new + #import­ant > a:focus:first-letter” means. An oldie but a goody.

Roger Johansson’s art­icle over at 456 Bereastreet on CSS 2.1 Selectors (part 1)

James John Malcolm MMXIV