insight

Beautiful HTML Typefaces (Seriously)

by Gerren Lamson December 15, 2009

Arial. Georgia. Verdana. Courier New. The list of safe, compatible fonts for the web has been very short, for many years. See them in action at Typetester. Much to the delight of designers, developers have been coming out with ways to remove the barrier between all typefaces and HTML. Although this might not be a good idea, let's take a look at:

@font-face CSS
The Solution: This CSS code allows visitors to download fonts from the site's server and display them on a webpage. When it's not supported, users see alternate html text (Arial, etc.) instead. Pretty neat stuff. Check out Font-Face.com, Mozilla's article, ALA's CSS-at-ten article, Tangerine's post, and this W3 page.
The Challenges: Licensing and compatibility are the biggest roadblocks. Many foundries don't license their fonts for the web, so you're stuck with free fonts (good luck!), this short list, and maybe these, too. Some browsers support @font-face and others don’t, and some take fancy footwork (Internet Explorer 4.0+ —  I'm talking about you and your EOT file format. Check out this post about how to achieve cross-browser support.

Typekit
The Solution: Using @font-face, Typekit offers a library of licensed fonts that consumers pay to use on their websites.
The Challenges: Browser-compatibility issues. Moderate pricing. Fonts may render poorly at 72-100 dpi screen resolution because they were designed for 300 dpi. And, while they have about 400 fonts available right now, they're missing good ones — the entire Hoefler & Frere-Jones library, for instance.

Foundry Example: Typotheque
The Solution: Typotheque is a font foundry that offers web licensing directly to their customers, who can use @font-face to implement them.
The Challenges: Browser compatibility issues. High prices  — a web license for one font runs around $26, so you better really love the way that font looks!  Also, all your favorite foundries will need to have a web license option if you want to use your favorite fonts.

sIFR (Scalable Inman Flash Replacement)
The Solution: sIFR is a flash-based solution that uses a .SWF, CSS, and JavaScript to render typefaces in HTML. Learn more: Davidson's overview, see an example, browse the official forum, and generate sIFR online.
The Challenges: Although it's compatible with 90% of browsers, it won't display your custom fonts if users have Flash or JavaScript disabled. They'll see standard HTML text instead. Plus there's no support for mobile, yet.

Typeface.js
The Solution: Typeface.js is a simple JavaScript-based solution that embeds custom fonts into a webpage.
The Challenges: You have to use fonts in TrueType/OpenType, so the JavaScript can read it. Licensing is still an issue. Very poor cross-browser compatibility: Anything before Firefox 1.5, Safari 2.0, or IE 6.0 doesn't work. Also, body copy will bog down page loading, and there's no link-hover support.

So, what should designers do? Since @font-face and sIFR both support standard HTML text replacement in the event your custom fonts don't display, I recommend trying it on the headers of your next web project. See if it's worth the extra effort for you and your client.

Comments

Add comment


 

biuquote
  • Comment
  • Preview
Loading



The way we see it, people who share insight with each other innovate, grow and succeed together.

Subscribe

Log in

The opinions contained in these pages do not necessarily reflect those of Springbox or its parent company, DG FastChannel.