Absolute Font Sizes: A Clarification

Web Review
December 1999

Over the last few months, we've explored the many ways to set the size of fonts using CSS. In the process, however, I glossed over some points and was perhaps misleading on some others. Fortunately, someone was there to catch me at it and not only point out the flaws in my rhetoric, but also provide some of his own.

Identifying the Problem

Todd Fahrner is a Web designer whom many CSS veterans know as one of the most knowledgeable and prolific contributors to the CSS newsgroup, and the author of a number of excellent articles on the subjects of fonts and font sizes on the Web. Among these are Why Points Suck, The Amazing Em Unit, Beyond the FONT Tag: Practical HTML text styling, and Toward a standard font size interval system; these articles should be read by every serious Web designer. Todd wrote to me with some concerns over my first article, and specifically over the description of the absolute-size keywords such as (xx-small and medium). As I described them:

The thing about absolute sizes is that they'll never change regardless of what the user does (short of turning off style sheets, of course). Once the absolute-size keywords are used on an element, that element's font size is locked. If users try to resize text through their browsers, elements with an absolute font size won't change, but non-absolute elements will. This prevents users from making your page's text larger if they need to see it more clearly, or smaller if they think it's too big.

This is an accurate description of how current browsers behave, but the problem is that it sounds like it's the Way Things Should Be-- which it isn't, as we'll see in a moment. I then compounded this mistake by introducing the following error:

The CSS specification says that each of these absolute sizes is assigned to a specific font size, and that these values never change.

This is not actually true. If you work at it, you can wrest such an interpretation from the language in the specification. However, you really shouldn't do so. As Todd says:

So the values assigned to the keywords are to be computed based on a host of (variable!) environmental factors, the first of which we might reasonably presume to be the user's preferred absolute length size (medium).

This is actually an interesting point, because it gets back to the problematic intersection between HTML and CSS font-sizing. As I observed in the original article, and as Todd explains in rigorous detail in his article Toward a standard font size interval system, there are seven HTML font sizes, and seven absolute-length keywords in CSS. The problem is that the HTML default size is 3, which corresponds to small in the progression of absolute size keywords, not medium. Thus, Internet Explorer assumes the default font size to be equivalent in size to small, whereas Navigator assumes it to be equivalent to the semantically more obvious medium.

Imagining A Better Way

Obviously, some harmonization needs to occur. However, regardless of a given browser's actual default size, an even bigger problem is that browsers tend to assign specific, unchanging sizes to the absolute-size keywords and never, ever let them be changed. Todd describes a superior alternative:

I assert that if the user changes [his or her] font size preference six times per minute, then the UA should recompute the table of absolute font size values half a dozen times per minute.

This is indeed a better way for the absolute-size keywords to work. The fact that most browsers don't do it is a shame, and a serious barrier to good Web design. It isn't hard to understand why browsers act as they do: after all, the very name absolute-size keyword implies that they are always the same, always unchanging. In this light, perhaps we can forgive vendors for their interpretation of this passage in CSS2:

An absolute-size keyword refers to an entry in a table of font sizes computed and kept by the user agent... Different media may need different scaling factors... Also, the user agent should take the quality and availability of fonts into account when computing the table. The table may be different from one font family to another.

If the absolute-size keywords were recomputed with respect to the user's preferences, then they could become a valid alternative to other scalable font sizes-- the em unit and percentages. Todd continued:

The absolutely unique (and endangered) benefit of absolute size keywords is that user agents can assign different absolute length values to the keywords based on user preferences or needs, the quality of fonts, available resolution, etc.-- stuff that authors can't possibly know a priori. For this reason, the keywords can/should indeed be user scalable. They are called "absolute" not to imply redundancy with absolute lengths, but (a) to distinguish them from the *relative* size keywords "larger" and "smaller" and (b) to indicate that their values are not relative to the size of the parent element in the document tree, as are the relative length units em and percent.

Back to Reality

While this all very true, it is necessary to keep in mind that current Web browsers don't behave in this fashion. It would better if they did, but for now we're stuck with what I'll call sub-optimal behavior. Hopefully, the browser vendors will see why the approach Todd describes is superior to what we see now, and will make absolute-size keywords something we can use more often in our Web designs.