It’s easy to blame browser compatibility for the frankenstein approach since getting IE to even recognize the new html5 elements in the first place means running a script to create them. And then you have to run the DOM in FF 2 and Camino 1 to keep them from closing elements improperly.

Requiring javascript just to make html work in these browsers seems self-serving, at best. But it starts to feel a lot less selfish when the client needs full control over heavily styled font. By working to avoid shocking browsers into handling html5 components and using @font-face, you’re simply avoiding one hack by implementing another. For us, the another hack has been sIFR.

The side effects of sIFR are such that alternate font replacement solutions like Typekit and Kernest start to look really good, regardless of any required javascript. And if they look really good, why not just hit Font Squirrel and deliver your own fonts, right? Right.

We decided to use @font-face on a project early enough to actually get the web-licensable fonts into photoshop from the outset. This instead of searching for a font that looked like Gotham after the fact. (I’m kidding about Gotham. Kind of.) @font-face implementation was simple – Paul Irish’s recommendations had made it into the Font Squirrel kits by the time I’d read it, making it all incredibly fast and simple.

We had a problem, though, with the fonts we were using. Being able to fall back to a web safe font in the stack is great so long as it’s similar to the one above it. Ours wasn’t — the intended font is significantly narrower than any web safe font, so in order to fall back to a readable alternative, we needed to reduce its font-size. In a second instance, we wanted a heavier font-weight for the web safe alternative. The font-family stack wasn’t enough.

I’d actually forgotten about Modernizr and was gagging on jquery browser sniffing when Joe reminded me. Modernizr allows you to specify alternate attributes for each instance (e.g., section h1 {} and .no-fontface section h1 {}) on any browser unable to render @font-face rather than having to detect user agents and then deliver alternate style sheets. As a bonus, it does the work the html5 shiv script I linked to above does, allowing us to knock down two birds with one stone and use actual html5 elements like header, nav, section, etc.

So now our build has valid html5 components and first choice fonts without requiring a bunch of hacks, and I have yet to find a single browser that chokes on the code. We’re still weeks out from launch and have a good deal of testing yet to complete, but the recent changes to Font Squirrel kits and now Modernizr have taken care of any significant reservation I had, at least for this project.

I probably could’ve sunk this entire post by tweeting a suggestion to spend 20 minutes familiarizing / re-familiarizing yourselves with both Font Squirrel and Modernizr and then maybe followed up asking how many of you employed html5 and/or @font-face for client work. But, I felt like typing. And, I have trouble avoiding vague references to movies older than half the population on twitter.

What do you think? You can twitter your words at me, too.