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?

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

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­ure 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 do this already when it comes to system-fonts, which means web developers expect this to work. Falling back to the reg­u­lar style (font-style:normal) is hor­rible as you lose all styl­ing in a text.
• 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 a 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.)
• Using 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.

Hi Internet! Happy New Year! Here’s a list of the best web­logs on the inter­net in 2009:

1. Kottke.org. Run expertly by Jason Kottke — live from New York — the blog links to new inter­est­ing things every hour of the day (except week­ends). Sometimes the links have little accom­pa­ny­ing notes, some­times it’s just straight-up link­age when it’s clear enough.

The end. Stay tuned for a new list next year!

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!

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!):

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).

Rain.

Hong Kong (via space­ships via talkev)

Good Example: YouWorkForThem:

Nice clear ver­tical design from YouWorkForThem. Good use of fixed pos­i­tion­ing for the pagination.

Ootje Oxenaar designer of the most beau­ti­ful bank­notes in the world. (Guilder notes, now replaced by the euro) – via www.creativereview.co.uk