280 HOW: Style Sheets for Designers: Trouble in Paradise
Absolute size keywords
There are seven absolute size keywords in CSS Level 1:
xx-small medium |
large |
x-small |
x-large |
small |
xx-large |
If implemented correctly and uniformly, these seven keywords would allow designers to specify approximate sizes without running into the accessibility problems associated with pixels. For that reason, the W3C recommends their use. The W3C is wise, and the recommendation is sound—except that it fails in too many browsers.
One size fits nobody
Unfortunately, absolute size keywords are unusable in many browsers. Netscape 4 largely ignores them. Netscape 4.5 and higher and IE3 render them at illegible sizes. (For instance, Netscape 4.5 and IE3 render xx-small at 6 pixels, which is 3 pixels below the threshold of legibility.) In Netscape’s case, the engineers were following an early recommendation of the W3C, which was that each size should be 1.5 times larger than the size below it. If small was 10 pixels, medium (one size larger) would be 15 pixels.
The W3C later changed its recommendation, but not before Netscape had followed it. We can’t fault Netscape for trying to support standards that changed, but we can point out the absurdity of using absolute size keywords if even one of your visitors is using Netscape 4 or IE3. And millions of folks use those browsers.
Small means medium, war means peace
Does IE5.x/Windows get it right? Not in our estimation. In IE5.x/Windows, there is a logical disconnection between the keyword and the way it is rendered. “Small” is displayed as medium; “medium” is larger than normal; and so on. (IE/Windows gets keywords right.)
The engineers who developed IE for Windows are not hacks and are not evil. They were trying to do the right thing. Remember the seven <FONT SIZE> settings supported by Netscape? Sure you do—<FONT SIZE=1>, <FONT SIZE=4>, and so on. Rather deftly and cleverly, the IE developers mapped
Taking Your Talent to the Web |
281 |
the seven CSS keywords directly to the seven Netscape font sizes. In many ways, it was a logical and even brilliant thing to do. (The IE/Windows developers were also the first group to attempt to support absolute font size keywords. We should credit them for that before carping about the results.)
The problem, of course, is that, logically, the sizes do not map to the keywords. In old-style browsers, <FONT SIZE=3> is the default or normal size that the user has specified in her preferences. In Netscape’s extended HTML markup, <FONT SIZE=3> is assumed unless you specify another size. Logically, a default size should map to the “medium” CSS keyword. Unfortunately, in the IE/Windows scheme, <FONT SIZE=3> maps to “small” instead of “medium” because small is the third size up from the bottom of the list.
Who goofed—the W3C or the IE/Windows team? It doesn’t really matter. What matters is that the keywords don’t map to expected sizes, and an incompatibility exists not only between different manufacturers’ browsers but between the Mac and Windows versions of the same browser.
If you think of the seven sizes the way the IE/Windows team did, your sizes will be off on Mac users’ desktops. (You also will go nuts. It’s like trying to drive a car where Park means Neutral.) If you think of them the way the keywords actually read (small, medium, large) your display will be off in Windows. You can trick the Mac browser into emulating Windows behavior by specifying a <DOCTYPE> of HTML 4 Transitional and leaving off the W3C URL. (For details, see http://www.alistapart.com/stories/ie5mac. But this is forcing the browser to emulate nonstandard behavior, and that's not good. Besides, it won't work in Netscape 4, Opera, or Konqueror.
So what can you do? Sadly, until your entire audeince uses browsers that render absolute keywords, all you can do is ignore the W3C recommendations and use pixels in your style sheet. Or do not use sizes at all.
Relative keywords
Relative keywords are limited to two: smaller and larger. These in turn refer to the size of the parent element. For example, consider the following example, in which the <BODY> is 12px, and <BOLD> is “larger.”
282 HOW: Style Sheets for Designers: Trouble in Paradise
<HTML>
<STYLE TYPE=”text/css”> <!--
BODY {font: 12px verdana, arial, geneva;} B {font-weight: bold; font-size: larger;} -->
</STYLE>
Bold type would theoretically be 14px tall in this example because 14px is one “notch” up from 12px. Like absolute size keywords, relative keywords are ignored or bungled in some popular browsers (Explorer 3 ignores them, as does Navigator 4 for the Mac). And even if they worked correctly, they would be insufficient for the needs of most web designers and their clients. Normal, larger, and smaller is not exactly a robust vocabulary for the needs of professional designers.
So what can you do? You can use pixels in your style sheet; that’s what you can do.
Length units
Length units sound smutty (those W3C folks should get out more…or maybe it’s just us) and include the following:
■em—Is a unit of distance equal to the point size of a font. In 14pt. type, an em is 14pts. wide—named for the size of the capital “M.” But you knew that.)
■ex—Refers to the height of lowercase letters.
When used with the font-size property, em and ex units refer to the font size of the parent element.
<HTML>
<STYLE TYPE=”text/css”> <!--
BODY {font: 12px verdana, arial, geneva, sans-serif;} STRONG {font-weight: bold; font-size: 2em;}
--> </STYLE>
Taking Your Talent to the Web |
283 |
In this example, <STRONG> would be 24px tall, or 2em (two times the font size of the parent element, which is the <BODY> tag). In theory, a web designer could create a layout using em or ex units, where all elements were sized relative to each other. This would avoid the accessibility problems associated with pixels.
Unfortunately, the browsers make this impossible for the time being. Netscape 4 ignores em and ex units. IE3 treats em units as pixels. Thus, 2em is mistranslated as 2 pixels tall. It takes a village to raise a child, and it takes at least 9 pixels to render a font. Length units are therefore not recommended. What is recommended? Pixels or nothing.
Percentage units
Percentage units, like length units and relative keywords, refer to the size of the parent element.
<HTML>
<STYLE TYPE=”text/css”> <!--
BODY {font: 12px verdana, arial, geneva, sans-serif;} STRONG {font-weight: bold; font-size: 200%;}
--> </STYLE>
In this example, <STRONG> would be 24px tall, or 200% of the font size of the parent element, which is the <BODY> tag. In theory (notice how we keep saying “in theory"?), a web designer could create a layout using percentages and avoid the accessibility problems associated with pixels.
Nothing is sadder than the murder of a beautiful theory by a gang of ugly facts. Netscape 4 for Mac renders percentage units when they are used for line-height (leading) but ignores them entirely when they are used to specify type sizes. And some versions of Netscape 4 for Windows treat percentages as pixels. (Thus, 200% is dementedly translated as 200 pixels. Mmm, nice layout.)