Web builders must deal with conflicting goals when working
with font size specifications on a Web page. One goal is to control font sizes
so the text fits the page layout and text elements (such as headings, body
text, and footnotes) have the appropriate relative sizes. The other goal, as
dictated by usability and accessibility guidelines, is to allow site visitors
to resize the text display in their browsers to meet their own viewing needs
and preferences.

When it comes to specifying font sizes with CSS, you have
three choices, each with its own advantages and disadvantages:

  • Absolute
    measurements (pixels, points, etc.)
  • Relative
    measurements (ems and percents)
  • Keywords
    (small, large, and so on)

What about absolute measurements?

Absolute measurements (specifically, pixels for screen
display) are the unchallenged champion of precision font-sizing control. Fonts
sized in pixels display the same on all platforms and in major browsers, old
and new (with a few minor exceptions). Furthermore, you can use the same
absolute measurement for sizing and positioning other page elements (such as
images, tables, and divs), which makes it easy to
control the relationships of those elements to the text.

The only drawback to absolute measurements for font sizing
is that they are consistent to a fault. Most visitors can’t adjust their
browsers to display pixel-sized fonts larger or smaller. This means that, for
example, visitors with vision problems or exceptionally high-resolution
monitors must view your page with uncomfortably small text because they can’t
use browser settings to display the text at a more appropriate size.

The inability to resize pixel-sized fonts is primarily a
problem for the Windows version of Internet Explorer. Most other popular
browsers, including IE5/Mac, support some form of Text Zoom feature to resize
text displayed in the browser window regardless of how the font size is
specified. However, anything that is a problem in IE/Windows is a problem for
the overwhelming majority of Web visitors, which means that pixel-sized fonts
can create accessibility issues for most Web visitors.

Relative measurements are a relatively poor solution

Relative measurements enable you to specify font size as a
relative enlargement or reduction of a reference font size. If you (or the
visitor) change the size of the reference font, all the fonts that are sized
with relative measurements change proportionately to maintain the same size
relationship with the reference font. In theory, this gives Web builders good
flexibility in sizing fonts while also addressing the accessibility issue by
allowing visitors to resize their text display.

However, as I pointed out in “The
trouble with using ems and percents for font
sizing,”
relative measurements have a problem that makes them
difficult to use in many real-world situations. The relative measurements are
based on the font size in the parent element instead of a fixed standard. This
means that using relative measurements for fonts within nested elements can
result in a compounding effect that quickly exaggerates any relative size
change. Small text becomes tiny and large text becomes huge.

Keywords: The key to compromise

The other font-sizing option is to use keywords. The seven
keywords (xx-small, x-small, small, medium, large,
x-large, xx-large) provide a reasonable range of sizes, even though those sizes
are rather arbitrary and not pixel-precise in their implementation in various
browsers.

All the major browsers support resizing text sized with
keywords, so there are no serious accessibility issues. The size adjustments
are in arbitrary jumps, but it’s a workable solution in most cases.
Furthermore, most browsers restrict the minimum font size for keyword-sized
text to 9px, so the text is never too small to read—no matter how visitors adjust
their browser settings. In some cases, this restriction might eliminate the
size difference between the smallest keywords, but at least all the text
remains legible.

Not a perfect solution

Keywords appear to be a workable, if not ideal, solution to font
size specifications in CSS. Unfortunately, CSS font size keywords’ bad
reputation for inconsistent implementation early on led many Web builders to
avoid them.

One problem with keywords is that the first implementation
of the concept called for each size to be 1.5 times larger than the next
smaller size, producing exaggerated size differences between each keyword. The
specification was later changed to use a more reasonable factor of 1.2, but not
before some browsers implemented keywords with the larger size steps.

Another problem with CSS keywords is a flawed mapping of
HTML’s numeric font sizes. The default size for normal text in most browsers
was HTML size 3. Therefore, some browsers mapped the default text size to be
the “small” keyword because that’s the third size up from the
smallest instead of the more logical “medium” keyword.

The current implementation of keywords in most major
browsers corrects both of these problems. The size increments between keywords
are visually appropriate, and text defaults to the medium size if no other size
is specified. However, this correction of previous problems creates a problem
of its own: browser incompatibility. CSS styles that produce the desired result
in current browsers may not produce the same results in older browsers.

The solution to browser incompatibility when using keywords
to specify font sizes is to set one font size for current browsers and use CSS
code hacks to feed different font sizes to older browsers. The technique is the
same as the Box Model Hack, which is commonly used to provide different margin,
padding, and size values for older browsers. Hacks such as this are messy, but
they’re an unfortunate fact of life that Web builders must contend with as long
as significant numbers of old, nonstandards-compliant
browsers remain in use.