More Fun With Font Sizes

Web Review
October 1999

In my last article, I explored two ways to set font sizes: absolute-size keywords, and relative-size keywords. In each case, we saw that there were a number of advantages and drawbacks to each approach. This month, we're going to repeat this exploration with two other ways to set font sizes: length units, and percentage units. Again, each method will be shown to have unique advantages and disadvantages.

Length Units

Using length units to set font sizes is perhaps the most popular approach. This is because so many of us are used to word processors and desktop publishing programs, in which we're invited to set the size of text using "points" or even a ruler unit like "inches."

As it happens, these are two of the eight lengths one can use to set font size:

The first five of these units are called absolute length units. This is due to their correspondence to real-world units which are assumed to have standard, unvarying lengths which always have the same relation to each other. The last three are a bit more fluid, and are therefore known as relative length units. The differences between these are important, and will emerge as we talk about how font size works.

Let's say that we want to create text which is exactly 18 pixels in height. This would be accomplished using the rule font-size: 18px;, with results something like this:

Hey, it's 18-pixel text!

Similarly, let's say that we want text which is nine points in size, which is useful for small text in printouts. That would work something like this: 

P.footer {font-size: 9pt;}

Wow, 9-point text!

This is all very easy, of course-- or so it first seems. This is all very clean in a vacuum, but once you start considering outside factors like operating system features, multiple media, and (as always) browser bugs, the picture becomes a lot less rosy.

The Dangers of Length Units

Okay, so we can set text size using relatively familiar, seemingly comfortable units. Why is that bad? There are two very fundamental reasons.

First off, we have browser bugs. A great example is Internet Explorer 3.x, which handles pixels badly in print. On a computer monitor, pixels generally measure anywhere from 72ppi (pixels per inch) to 120ppi. Laser printers, on the other hand, run at least 300ppi. It would be sensible that a browser's printing code would perform some sort of scaling, and most do, but not IE3. It will print out 12px text as 12 dots high, which means that the text will be 12/300 of an inch tall-- in other words, it will be 1/25 of an inch tall. This is really, really hard to read, even with a good magnifying glass.

While this may seem like just another boneheaded coding error, it actually illustrates a fundamental danger of the Web: you can never assume that the display medium of a document is controllable by you, the author. Just because you tell users that they should make their browser windows 800 pixels wide, and set their font to 12-point Times, doesn't mean that they will... or even that they should. Maybe they're using a 640x480 monitor in a public library where they can't change the browser's preferences. Maybe they're using a text-based browser like Lynx. Regardless of the circumstances, a page designer must always remember that the user experience is not controllable, and that any attempts to exert "total control" over the appearance of a Web page are doomed to futility.

With that in mind, length units are dangerous precisely because they provide the illusion of control. It's a very powerful illusion, since so many browsers will honor these length units. But take another example: setting text to a certain number of points will yield different results in different operating systems. If you set 9pt text next to an image, it will look very different in Windows than on a Mac, or under Unix. (In fact, you will likely see differences even among different Unices.)

This is because in order to turn "points" into a measure which the computer can use to display the text on a monitor, it has to be translated into a certain number of pixels. To do this, the operating system maintains a scaling factor... and every operating system, it seems, has a different factor. For that matter, on some systems (including many Windows systems), the user can set this scaling factor.

Thanks to these differences, what looks good under one operating system can be completely unreadable on another. Many Windows-based authors are fond of using 8-point Arial, because it looks compact, clear, and futuristic when they preview their own pages. Load up these same pages on a Macintosh, however, and you can unreadably small text, because the point-to-pixel scaling factor is different for Macs than it is for Windows-- plus many Macintosh systems do not include Arial. Figure 1 shows some results of viewing a Windows-centric design on a Macintosh.


Figure 1. 8pt text on a Macintosh.

You can't get away with just dismissing this as a "fringe market" problem. Similar issues will arise with many Unix systems, and in the rapidly growing handheld computing market. These users should be just as important to you as Windows users, so you do need to think about how you can make sure that they can access your information.

Relative Lengths To The Rescue!

There is a way around all of this, and that's to use relative lengths for your font sizes. Doing so is easy: try the following stylesheet on a page of your own.

H1 {font-size: 2.5em;}
H2 {font-size: 2em;}
H3 {font-size: 1.5em;}
H4 {font-size: 1.25em;}
P.footer {font-size: 0.8em;}

This will set your text such that H1 elements have a font-size which is 2.5 times that of unstyled text, H2 elements will be twice the size of normal text, paragraphs of class footer will have text 80% normal size, and so on.

Actually, that's not exactly correct. In fact, the rule H1 {font-size: 2.5em;} will cause text to have a font-size of 2.5 times its parent element. The distinction is crucial: if an H1 element is the child of a DIV whose font-size is twice normal, then the text of that H1 will be 2.5 times twice normal, or 5 times larger than unstyled text. (For more examples of how this can be problem, see last month's article.)

In other words, if you're going to use relative length units, you have to be careful about your document structure-- but since you're supposed to be careful about structure in the first place, this shouldn't be a burden. If it is, you probably need more work on your document-authoring skills.

Using ex units should be, in theory, no different than using em units, except of course in that ex units can represent a smaller distance than em units. In practice, one ex is equal to one-half em (a grossly inaccurate oversimplification of the relationship between em and ex, but never mind that now). However, since em units can act as simple multipliers, they're much easier to use.

The other advantage of using relative-size units is that all text will be sized in relation to the user's preferences. This allows the author's ideas of how text should be sized to be expressed in relation to the basic text size the user is comfortable reading.

Percentages

In a manner similar to em units, percentages can act as multipliers of font size. Here's a stylesheet which is theoretically equivalent to the one above: 

H1 {font-size: 250%;}
H2 {font-size: 200%;}
H3 {font-size: 150%;}
H4 {font-size: 125%;}
P.footer {font-size: 80%;}

Again, you have to be careful about document structure and how your styles interact, because you can end up with insanely large (or small) text with a careless set of rules. For example, take this markup-- which I've seen before-- and apply the above stylesheet to it: 

<H1><H1>An H1 Element</H1></H1>

In this case, the H1 element's text will be 250% of 250% of normal size, or 625% normal size!

Relative-Size Dangers

Most of the problems encountered with relative sizes are concentrated in Internet Explorer 3.x, which has a whole host of bugs. Most greivous is the fact that font-size em units are interpreted as pixels, so the declaration font-size: 2em is functionally equivalent to font-size: 2px, at least as far as IE3 is concerned. This make it difficult, if not impossible, to use em units and still have documents readable in IE3.

Percentages do not suffer from this problem, but have one of their own. Under IE3, percentages are calculated with respect to the normal size of the element, instead of the element's parent. Thus, if you set H1 {font-size: 200%;}, and IE3 already assumes that H1 text is twice as big as unstyled text, then the final result is that H1 text will be 400% normal size. This is not nearly as bad as the problems with em units, but it's still a concern-- one which you should consider carefully before preoceeding with percentage-based font sizes.

In Conclusion

Despite the drawbacks involved, I hope that I've shown, both this month and last, that relative sizing is far superior to absolute sizes. Even though there are some bugs to dance around, relative sizes allow the author to size text in relation to the user's preferences, instead of trying to override them. In addition, with relative sizes, it's easy to avoid the kinds of platform- and media-dependent problems which absolute font sizes so often introduce.

Next month, we'll wrap up this font-size series with a look at how you can use this advice in the real world, and how it's sometimes desirable to mix absolute and relative sizes into a single stylesheet.