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.

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

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…

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 a out­dated link which 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…

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…

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:

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

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:

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.