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

Improve your WordPress: related posts for 404’s

Second in a series of art­icles about tinker­ing with improv­ing your WordPress install­a­tion, we return to cus­tom 404 error pages; adding a list of pos­sibly related posts when vis­it­ors have fol­lowed an out­dated link. Other 404 error page improve­ments can be found in the first art­icle of this series.

One of the most use­ful things on a 404 page is a dir­ect link to the page vis­it­ors were try­ing to get to. Now we can’t read minds, but we do know the URI (explained in the third para­graph of the pre­vi­ous art­icle) and that’s good enough. The fol­low­ing code is adap­ted from this archGFX art­icle. The method used to trans­form the URI into a search query is very simple. If you would like a more advanced please refer to “A bet­ter 404 — Redux” at Urban Mainframe, where Jonathan Hollin expounds on his (down­load­able!) 404 page code.

There are two parts to this “related posts” code. The first part makes it pos­sible to get from “/wrong/link.html” (the URI) to “wrong link” (the search query). Read the rest…

Improve your WordPress: the 404 error page

First in a series of art­icles about tinker­ing with improv­ing your word­press install­a­tion, today we tackle cus­tom 404 error pages; the page every­one dreads get­ting when they’ve fol­lowed an out­dated link.

Four-Oh-Fours are hot again! Just recently came a across the art­icle A Better 404. I remem­ber read­ing the A List Apart art­icle “A Perfect 404″ ages ago, but had never done any­thing about it. Time to improve.

First some quick vocab: the part after your .com (or .co.uk) is called the URI, so if www.google.com/analytics/provision/ is the address,  /analytics/provision/ would be the URI. The URI is the part that’s wrong when someone’s fol­lowed an out­dated link. This means we can use the URI to cre­ate a more help­ful 404 page. To cre­ate a 404 page for your WordPress theme just cre­ate a 404.php file in the dir­ect­ory of your theme (/wp-content/themes/default/ is the default). Read the rest…

Inserting pages into category archives in wordpress

Wouldn’t it be handy if you could have a little story at the top of your archive pages (or other tem­plates), explain­ing exactly what’s what? And wouldn’t it be handy if that little story was fully wysi­wyg edit­able? I thought so.

Sites in WordPress (WP) have “posts” which go into cat­egor­ies and “pages”, which are inde­pend­ent. My cun­ning plan was to name pages exactly the same as the cat­egor­ies I wanted them to describe, and then insert them into the archive page. It has been quite a search to get all the right code, even though the end res­ult looks quite simple!

The first thing you do, is cre­ate a cat­egory (”One & One”) and cre­ate a page (with the title “One & One”). Secondly, you open up your archive.php tem­plate file.

You should see some­thing like the fol­low­ing in it:

<?php if (have_posts()) : ?>

And also, fur­ther along:

<?php while (have_posts()) : the_post(); ?>

Read the rest…

James John Malcolm MMXIV