For what can’t we blame the desktop publishing revolution?
Back when our Tim was inventing the interweb, being a science-faring man he considered one typeface more than enough for anyone. The important part of a document is the semantic content, after all. Though everyone was surely suffering desktop-publishing fatigue, grey with black text wasn’t very exciting either, and pretty soon the extensions were rolling in: most infamously the blink tag and the font tag.
With the advent of CSS1 we could have our cake and eat it, so long as the cake had arial, courier, or times-new-roman icing (although, in principle, the CSS property
font-family allows any font to be specified, the only fonts that can be relied on to be present are Arial, Times New Roman, and Courier New).
Naturally, both Microsoft and Netscape (who were still around) came up with their own way to embed fonts. Neither took off: Largely due to font licensing constraints (and, I suspect, end-user indifference), the technology was complicated to use and infrequently applied.
Print envy was typically satisfied by producing pictures of text in the desired font with the desired special effects. Later, when it became trendy to pay attention to standards and accessibility guidelines, however, it was clear that this approach was inadequate.
If it looks like a duck, it’s probably a canard
Pictures of text just aren’t the same as text, so using them instead introduces a number of problems:
* Images are typically unreadable by programs: screen reader software will miss them out and web crawlers will ignore them.
* Browser functions that operate on text (e.g., using the clipboard, searching) don’t work on pictures of text
* Images don’t scale when the user zooms the text size in their browser
* If the user switches off the display of images, the text will be invisible (the
alt attribute doesn’t always help here).
Enter dynamic image replacement
The idea with dynamic image replacement is to have play-nice, semantic markup in your HTML, and replace it with images if you can determine that it’s OK to do so—and do the substitution without breaking accessibility and usability. The various techniques (Google) differ in how they determine what’s “OK” and what they consider is “breaking”. There’s also the matter of with what they replace the text: for comparison I’m going to lump them into replacement-by-images and replacement-with-Flash.
Replacement with images
This technique relies on the fact that CSS concerned with display will be ignored by screen readers and web crawlers.
Dan Cederholm discusses image replacement in his excellent (and still very relevant) book, Web Standards Solutions. Taken together, the disadvantages of replacement-with-images techniques are
* The pictures of text and the text being replaced may both be completely hidden if the user opts not to display images
* Pictures of text don’t scale when the text size is scaled
* Regular browser functions like search and text selection are compromised.
* It’s more work for web site authors, because a graphic must be custom-made for each piece of replaced text.
Replacement with Flash
sIFR is the most comprehensive implementation of replacement with Flash I’ve seen. It does a better job than replacement with images for a few reasons:
* It can be made to scale text (sort of)
* It can replace arbitrary text (technically this can be done with images given a suitable server-side script), with several options for styling.
* There’s only one generic file needed, which can be cached
It still has some disadvantages though:
* Search and selection are still broken; text in the Flash animation can be selected, but not along with regular text
* You can’t put hyperlinks around Flash animations, and Flash buttons don’t behave like hyperlinks in anything but the most minimal sense.
* It’s really only good for using different fonts with some standard effects
Unfortunately, I suspect these are all insuperable problems; but they are not the end of the world, or of your site, by any means.
Unless you really have something against Flash (and if you’re really concerned about having the correct typeface on your site, chances are you don’t), Flash replacement is definitely worth considering.
Because of the broken browser functions, though, I would restrict it to main headings, and possibly only ones above the fold. By doing so, you’ll mitigate the problems with searching and text selection. I’d avoid replacing hyperlinks—it’s really not acceptable to replace hyperlinks with minimally-functional buttons, which will be a surprise and annoyance (Wikipedia) for most browser users.
* There is a discussion on font embedding with some historical details (and plenty of opinion) at http://www.typophile.com/node/9978.
* Joe Clark summarised the pros and cons of the original variety of image replacement at http://www.alistapart.com/articles/fir/.
* Virtual Graphic Artist has a history of the practice of typography, with some attention to how the Web is different from print.