Web typography - getting it right
Web design can be a very finnicky business. Quite often near enough is not good enough and we always aim to achieve the best result possible. However the expectation that you can achieve pixel perfect results in comparison to other formats such as print can be a difficult one to manage.
A couple of projects have highlighted the frustration of web typography for web designer, web developer and customers. Its my personal opinion that the focus of any web project should be functionality and usability above all as these are bigger things to solve. Graphic design is very important, but should work within the web medium and its limitations. However sometimes customers tend to micromanage design results and we need to compromise and employ methods that will keep everyone happy. So I thought I'd give a quick rundown on the issues and some of the solutions we've applied.
Standard Hypertext Markup Language (HTML) and Cascading Style Sheets (CSS) have well known limitations in these areas. The basic options is for choosing from a family of available fonts , text size, italicise or not italicise, bold or not bold all of which vary from computer to computer and browser to browser. Working within such limitations is a fundamental challenge for web designers.
The graphic below illustrates this variation.
All three of these have the same font settings. The top is in Photoshop (note the antialiasing applied), second is the website rendered by Mac OSX (no antialiasing but closely matching the boldness and size) and the third is a website font rendered in Windows (a little bit of bold and size variance).
While the variation seems natural to a web developer who understands the differenced between mediums the reality is that customers to whom branding is critical may not tolerate such variance.
Using Web "Safe" Fonts
Web safe fonts are fonts that are installed on every computer or web browser. The benefit is that all web standards support them. They can be freely used and can not only be manipulated by stylesheets, but a user can select and zoom them, important for usability. But they are also limited to fonts available on a user's system. The above example shows the results when even a web safe font is rendered at the whim of the operating system and browser.
Flash is not the Solution
In the 1990s, Flash was frequently used render websites with slick anti-aliased fonts and animation that would look virtually the same regardless of the browser. There are very good reasons why seldom use Flash in web design.
Font Replacement - A compromise ?
Font replacement is one other method. There are technologies that enable automatic replacement of text with images, some server side and some client side. Scalable Inman Flash Replacement (sIFR) and Cufon are two such technologies we've employed in the past. In the end, however it has often proven more trouble than its worth.
The problem we've found with these solutions is that their complexity which can cause more to go wrong. While they solve some typography issues, they create new issues in layout.
The concept of replacing a web safe font with itself (as shown in the example above) to achieve pixel perfection can also seem a little silly.
One recent project which we managed to overcome these isssues and used Cufon to good effect is the Westscheme website. Whereas we have applied sIFR for several projects including websites for the Australian Childcare Super Fund and Slade Recruitment.
Here are some of the pros and cons from our experience with projects like these.
- Typography Matching - because images are used, fonts can be nearly perfect matches across most browsers.
- Rendering Issues - we've seen several problems with font replacement, particularly as the images load with problems such as excessive flicker using Cufon. They can also adversely affect margins, line height and kerning (definition) in the website's layout
- Search engine optimisation - like Flash, using images instead of text can cause a penalty in Google Rankings. Others get around it, however they can be hit and miss unless you are careful.
- Usability - not all of the available font replacement technologies allow users to select text or resize text.
- Accessibility - an often overlooked area, many font replacement techniques have accessibility compliance problems such as issues with text to speech readers.
- Selective replacement problems - font replacement is not suitable for being used across an entire site. The site may as well be developed fully in Flash. Font replacement is typically limited to major headings and the like. Also as noted above, while other parts of the site can scale to user settings, the replaced fonts can remain out of whack.
New ways of looking at the issue are being explored all the time and some interesting methods are emerging. Like many designers we are also constantly looking at ways to solve it.
One such method is employed by this website which uses @font-face remote font embedding. CSS3 supports this technique and Datalink have been moving towards CSS3 as a standards based approach to web design and development. Using this method fonts are rendered natively and perform just like any web safe font would. We use a "font as a service" called Typekit for our own site which is subscription based but well worth it considering the quality of the result. Antialiasing and other effects can be automatically applied, however one downside we have found is that a variance in the computer's settings can degrade the appearance of the fonts substantially.
From our experience our approach is specific to each project and the chosen fonts from a company's visual identity. It remains a huge grey area in our profession and I'm interested in hearing from designers and clients of web designers to hear the results of technologies. Share your thoughts by commenting below.