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!

Just a quick note to com­mem­or­ate a design refresh of this site. Have been look­ing for ways to cre­ate seper­ate atten­tion for main text and the side­bar. Can’t say I haven’t been inspired by Jon Hicks (and oth­ers) who has also just imple­men­ted a differing-colour-main-part-with-border on his site. Kept the main nav in the middle, to add ugli­ness give the design a quirky edge. If I have time to put the search­bar up top the nav may be able to move over to the left.

You’ll notice the logo is a lot smal­ler. What can I say? My cream ran out, plain and simple. I’m much hap­pier with it, now it’s smal­ler. I’ve still to update the logos for the inspir­a­tion square.

The side­bar still suf­fers from mixed header styles head­ers have been updated too. Haven’t man­aged to add any other col­ours to the red & gold col­our scheme yet though!

Make sure you visit my (on site!) Tumblr page. An upcom­ing post will describe how I man­aged to cre­ate internal links to the con­tent there — the “latest inter­est­ing stuff” links in the side­bar are gen­er­ated on the fly.

Of course, if you find any quirks, let me know.

Good news! Google Chrome is get­ting full page zoom, and it’s the default! That only leaves Safari to imple­ment it, as IE, Firefox & Opera have had it for a while now. [1]

Full page zoom is import­ant because it means no more muck­ing about with elastic lay­outs (em-based) or liquid lay­outs (%-based). That just leaves fixed lay­outs (based on pixels), which is good because images, videos and other media are in pixels too!

Note: I’m not say­ing it’s good to use pixels for font-size: prop­er­ties! (Just all the other prop­er­ties, like height, width, mar­gin, pad­ding, etc.)

[1] Update: Safari 4 (beta) has imple­men­ted full page zoom too! All major and minor browsers have imple­men­ted full page zoom. Until wide­spread updat­ing of Safari 3 with 4 and (more import­antly) IE 6 with 7 or 8, approx. a quarter of vis­it­ors will only have text-based zoom avail­able to them. IE 6 users are likely not to know any­thing about zoom-capabilities however.

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…

Bug report­ing is tricky. Bugs are prob­lems in soft­ware where the soft­ware doesn’t work as it should. “It doesn’t work.” doesn’t get you any­where with the developer of the soft­ware in ques­tion, so the key is to report exactly what hap­pend and what should hap­pen very clearly. Steven Frank (of Panic, Inc. software-makers) has made a list explain­ing what you should and shouldn’t do when report­ing bugs. One of the things Frank spe­cific­ally men­tions as being good ways to con­vey bug reports are images and video.

A lot of open source pro­jects use Bugzilla (of Mozilla ori­gin) to track bugs and make dis­cus­sion of those bugs pos­sible. Shouldn’t Bugzilla make it pos­sible (and easy!) to include images and video in bug reports?

If Buzzfeed can do it…