Last time I had looked at @font-face, it was still pretty much theoretical. Now it turns out that the newest versions of most modern browsers support it – and IE is supported back to IE6! Sadly, Google Chrome isn’t showing us any love here.

Fortunately this technique doesn’t need any of those sly image replacement tricks we’ve wrestled with in the past; the browser just renders fonts as God (or Berners-Lee) intended. Hence, no problems with search engines, screenreaders and command-line Unix curmudgeons.

The only difference from normal font specification is in telling the browser where it can look to download the font if it’s not present. That’s where @font-face comes in. The whole thing is pretty easy to set up, too. Here’s where you can get some help:

CSS @ Ten: The Next Big Thing (old article)

Bulletproof @font-face syntax

Mo’ Bulletproofer @Font-Face CSS Syntax (This is the syntax I use.)

ttf2eot on the web! (Creates the special font format needed by IE)

One thing to look out for — it’s best if the downloaded font has similar metrics to the fallback font. The font I used on a recent project turned out to be quite small, and had to have the sizes jacked up in order to look right. That means that on browsers that don’t support font downloading, the fallback font looks huge. It’s still quite usable, though.

Typophiles and standards gurus, rejoice! The web is now looking a little more friendly to both crowds. Now if Google will just get with the program…

UPDATE: It appears that Google has fixed the problem with Chrome’s support of @font-face. It appears to work just fine in Chrome 4 for Windows!

The article mainly talks about the development efficiencies of using a standards-based approach, which are very real. But don’t forget that it also pays dividends in accessibility, browser compatibility, and search-engine-friendliness.

This is the not only the way of the future, it’s the way savvy web developers are doing all of their projects today. If your developer isn’t taking a web standards approach to your site, you need to know why.

• Label position Placing a label above an input field works better in most cases, because users aren’t forced to look separately at the label and the input field. Be careful to visually separate the label for the next input field from the previous input field.
• Alignment of labels In most cases, when placing labels to the left of input fields, using left-aligned labels imposes a heavy cognitive workload on users. Placing labels above input fields is preferable, but if you choose to place them to the left of input fields, at least make them right aligned.
• Bold labels Reading bold labels is a little bit more difficult for users, so it’s preferable to use plain text labels. However, when using bold labels, you might want to style the input fields not to have heavy borders.
• Drop-down list boxes Use them with care, because they’re so eye-catching. Either use them for important data or, when using them for less important data, place them well below more important input fields.
• Label placement for drop-down list boxes To ensure users are immediately aware of what you’re asking for, instead of using a separate label, make the default value for a drop-down list box the label. This will work for very long lists of items, because a user already has the purpose of the input field in mind before the default value disappears.

The author has started a project to write a book called “50 Redesigns from Scratch” which will be published in print and as a free (but less featureful) PDF version. The first couple of redesigns have been posted as previews.

I always love “before and after” design examples!

It all works really well with any browser except IE v5 and below. But even there, it degrades gracefully. Users without Javascript won’t see the rounded-corner and equal-height-column effects, but again, what they see won’t be too bad.

• Simple layout
• 3D effects, used sparingly
• Soft, neutral background colours
• Strong colour, used sparingly
• Cute icons, used sparingly
• Plenty of whitespace
• Nice big text

Check out the pretty pictures, and see if your site measures up.

Chris is a really nice guy, and a good teacher. I took his half-day tutorial about PHP Security at OSCON, and it really helped me understand things a lot better.

I haven’t read his new book yet, but the older one (”HTTP Developers Handbook”) is invaluable for understanding the interaction between the web server and the web client, and how to affect that interaction programatically.

Both techies and business folks can become enamored of shiny new web technologies and try to throw as many of them as possible into a site. But the best web sites focus on solving problems for real people, and doing it as simply as possible.

By all means learn new technologies and use them when it’s appropriate to do so. But first and foremost, find out who your target audience is and what those people need to do with your site. Then make sure you help them do it quickly and reliably.

The people will thank you for it.

Starting a web project without clearly knowing and communicating its purpose is a good way to waste a lot of time and money. This article gives some quick and easy ideas on creating a written objective and a statement of strategy. The piece is not detailed or comprehensive, but it should get you thinking in the right direction.

Not really very difficult. I followed some procedures in my “Upgrading to PHP5” book, but most of the tricky stuff was taken care of for me by the Debian packages. The PHP 5 package was a backport I got at www.dotdeb.org, since Debian doesn’t have it in either stable or testing. (If anyone wants to see details, let me know.)

All of my stuff just worked afterwards. Of course, I only have four domains and a handful of packages, so testing was relatively easy. I had thought about installing PHP 5 as a CGI for testing purposes, but then decided just to go for the gusto and replace the old version.

For complex sites the more cautious approach would probably be a good idea. There are some tricky incompatibilities between MySQL client and server versions that must be worked around, and there are a few OO things in PHP4 scripts that might break under PHP5.

Now I can start playing with all the stuff I’m reading about in “PHP5 Objects, Patterns and Practice.” It’s a *very* good book so far, and the OO concepts are starting to come together for me.