The Current State of Robust Typography on the Web – Part I

For quite some time designers have been looking for an effective way to create web designs using rich typography. Unfortunately there are not many web-safe fonts that will work with all browsers. One of the challenges that comes with front end development work is finding an appropriate solution to include fonts that are not web-safe on a website. There is no industry standard solution, and hasn’t been for years. The following are some of the techniques used for achieving rich typography on the web.

Image replacement is one of the earliest methods of producing rich text in web pages. As the name implies, image replacement involves using an image of the text set in the non-web font, then using some CSS styling it becomes the background of a container that has web-safe text in it which reads whatever the image says. The text within the container is given a negative indent to hide it resulting in just the background image.

The main advantage of using image replacement is that the text will look the same cross-browser, and the text that’s hidden will allow screen readers and search engines to “read” what it says. The disadvantage is that it’s only useful for headings that won’t change much as a new image would need to be exported every time the text needs to be updated.

A slightly more elegant solution is sIFR. sIFR stands for Scalable Inman Flash Replacement. What sIFR does is embed the non-web safe font into a Flash file, then it uses JavaScript to replace the letters of the sIFR’d text with small Flash files of the letters. The end result is that it can be scaled, it’s easier to update than regular image replacement, it’s accessible for screen readers and search engines, and if JavaScript and Flash are both disabled it simply reverts to regular web safe text.

It’s a pretty spiffy solution, but even the creator of sIFR have said that’s it’s a flawed one. The problem with sIFR is that the JavaScript parsing through the letters and replacing them with Flash files can get really intensive on browser resources. An entire page set it sIFR text can easily crash a browser, which means that it’s ideal for headings, but not so much for body copy. It’s also not a great solution for websites with a lot of JavaScript and rich media because of the strain it can cause, and it’s also problematic for mobile due to poor JavaScript and Flash support in most mobile browsers.

So how do you get body copy set to non-web fonts?   You could use Cufón. Cufón is a solution that converts a non-web safe font file to a JavaScript file, then the JavaScript reads it and uses HTML5 canvas (or VML for browsers that don’t support canvas) to draw each letter on the page. The end result is that the characters are all drawn on the page in the non-web safe font. It is selectable, visible to search engines and screen readers, and not as resource hungry as sIFR. This is a great solution; why not use it for every site?

In a word: licensing.

Font licensing is a big issue since websites that use some form of font-embedding techniques have the file hosted – so it can be downloaded just like an image file. That doesn’t sit well with type houses that can charge over $200 per license for a decent font family.  A site visitor just needs to look at the stylesheet and copy the path to the address bar to get to the font file. For this reason many font licenses either do not allow embedding within a website at all, only allow embedding within Flash (since it’s harder to get to and more secure), or charge a high fee for online embedding. You can always use image replacement with any font you have the rights to use in a design, as it’s not embedding the font. sIFR can be used on fonts where Flash embedding permitted, and for all other methods you need a license that allows online or web embedding which is rare both for security reasons, and sometimes it simply gets overlooked since it’s not a common consideration yet. If you are unsure whether or not a font license includes online embedding you need to contact the font foundry to ask whether the font license will allow it.

So how about a method where we don’t need to worry about licensing?  More on this in Part II….

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: