Web Fonts: From Fantasy to Reality

I really wanted to title this post, “Just Because You Can Use Comic Sans Doesn’t Mean You Should”, but that would have been a wholesale rip-off from the last slide of Mark Wyner’s presentation on Web typography from the recently concluded WebVisions 2010 conference. Mark gave a wonderfully balanced and seasoned look at the past, present, and future of Web font technologies and their application. Like many of us in the Web game, Mark is stoked by recent Web font developments. Lately, there’s been a groundswell for the adoption of the CSS @font-face directive for linking to server-based fonts and the WebOTF Proposal is currently being mulled over by the W3C and has gained favor with many of today’s leading type foundries. Taken together, these new tools give designers and developers the opportunity to expand their horizons when considering typographic choices for displaying content (no longer will we cower behind our Arial-led Web-safe font-stacks). Moreover, these new developments will give our clients the assurance that: a) their content will appear more consistent across all browsers and platforms and, b) their content will continue to be indexable, searchable, and accessible.

Where We Are

Here at Pop Art we’ve been happy using the sIFR font replacement strategy for awhile now. We mostly use it for headline copy (display type) as sIFR becomes unwieldy for longer passages of text. On the whole sIFR’s been really good to us. It’s a bit of a learning curve at first to implement well but once you get your hands dirty you can make sIFR do back-flips on command. sIFR really sings when asked to display our clients content consistently across the ever-expanding field of Web browsers and platforms. sIFR has its drawbacks of course. It requires the browser/user to have javascript turned on and have the Adobe Flash plug-in installed. Because sIFR replaces inline text with a Flash SWF it will remain inaccessible on iPhone and iPad devices as long as Apple and Adobe continue to caterwaul over who is more “open”.

Moving Forward

In order to move past sIFR to a true HTML/CSS solution like @font-face, I think a few things need to happen.

Before we can adapt @font-face wholesale, font rendering needs to improve across platforms. Many of today’s Web fonts, like those offered from services such as Typekit, Fontdeck, and the newly launched Google font API fail to render optimally on various browsers on the Windows platform. This is due to the way Windows handles font smoothing and a lack of good type hinting in available Web fonts. One need only browse (in the Windows environment) the selection of free fonts available now through Google to witness these less then optimal results.

Additionaly, more commonly used (and not so commonly used) font-families need to be released as optimized Web fonts. Luckily, here, things are improving at a rapid rate. Type foundries know this is the future of Web typography and are racing to release quality Web formatted font families that include various weights and sizes while also being well hinted and available at an optimally compressed file size. These new font families will hopefully stand up to the current handful of default Web-safe fonts.

The end goal—to give our client’s content the absolute best reach across all display environments while being able to style content with greater flexibility—is how we will continue to evaluate all the current tools available to us as designers and developers. The Web typography future is bright and it’s an exciting time to be working in the field.

No Comments on Web Fonts: From Fantasy to Reality

Comments on this entry are closed.