Enterprise Software

Are keywords the answer for font sizing?

When it comes to specifying font sizes with CSS, you have three choices: absolute measurements (pixels, points, etc.), relative measurements (ems and percents), and keywords (small, large, and so on). Here's why we think keywords are the best compromise solution.

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.

Editor's Picks