When moving from the design to the implementation of a website, there are literally countless ways to get started. Among the most important things to be mindful of are keeping the HTML and CSS as clean as possible, limiting the amount of Javascript, and having a clear, organized, and accountable plan for execution. In addition to these three considerations is the decision of how to handle type on your site. Since typography and the display of textual information is such an important element of site design, we all long for a better and more consistent approach to handling fonts than the solutions available to us today. Current methods include the CSS property called @font-face and Javascript solutions like sIFR and Cufón, each with their own drawbacks and limitations. Below we’ll take a closer look at each one of these options. None of them are perfect, but they do provide alternatives to traditional approaches to managing typography on the web.

@font-face
The @font-face is a CSS property that links to an embedded font with which to render the site’s text. It is currently only supported by Safari, Firefox and Opera. However, the @font-face requires the embedding of a font, making it available to anyone which raises licensing and legal concerns. For a more in-depth explanation of the current cross-browser compatibility issues and legal constraints surrounding font linking, check out the post by our typography expert, Joe, from back in March. He explains this all in great detail.

So until the W3C approved @font-face is supported by all browsers and all the legal issues are sorted out, there are only a few methods being put to use which allow the use of any typeface on websites. Two of the most popular methods are sIFR and Cufón. Both are SEO friendly and require the use of Javascript but will degrade to the standard CSS font styles if Javascipt is not enabled. Both are relatively easy to set up, and once implemented, they will dynamically replace specified text areas with custom fonts of your choosing.

Cufón
Cufón, using Javascript and an embedded font, dynamically redraws the specified text. It is fairly easy and straightforward to implement.

sIFR
This is the current method used to display titles throughout our website and blog. sIFR, short for Scalable Inman Flash Replacement, is a DOM replacement method which uses a .swf containing the embedded typeface to render the font and a little bit of Javascript to replace the page’s text with that Flash object. You can see examples of this in the drop cap that begins this post and in the text below.

The quick brown fox jumps over a lazy dog.

sIFR vs. Cufón

• sIFR text is still selectable.
• sIFR text can have hover states.
• sIFR supports drop-shadows and anti-aliasing of text.
• sIFR prevents direct access to the embedded font. *
• Cufón is quicker to set up and has faster loading times.
• Cufón relies solely on Javascript. There is no need for extra Flash files.
• Cufón can be used with large blocks of text.

* Adobe Flash allows the embedding of purchased fonts within Flash objects. Using sIFR to embed a font is very similar to embedding a font on a Flash website. Some argue that this is still an issue, because anyone can just steal the .swf file with the embedded font and reuse it with sIFR on another site.

sIFR is a little trickier to set up and use, but there are too many legal issues surrounding how typefaces are embedded using the @font-face and Cufón methods, which is why sIFR is your best bet. So, since we keep coming back to the same legal and licensing problems with embedding fonts, shouldn’t we start exploring other methods of using fonts on the web? Good news is that webfont services are here! Typekit and Fontdeck are currently in production and awaiting release, while Kernest was launched about a month ago, becoming the first font service to sell a commercial webfont license.

Webfont services like Kernest are attempting to solve licensing problems by providing a one-stop shop for using licensed and legal fonts on the web while compensating the creatives behind the type. With webfont services, foundries and type designers will actually be involved in the distribution of their fonts. And additional layers of protection will be provided to make sure only authorized sites are allowed access. For more on this, check out Ralf Herrmann’s article on “Why webfont services are the future of fonts on the web.”