Web Site Design by David Rutstein from A to Z

The trouble with pixels has been discussed earlier in this book and chapter and mainly comes down to this: In IE/Windows, users cannot resize text set in pixels. If you’ve used 9px type for your site’s body text, many visitors will click their browser’s Back button faster than you can say squint.

Even 11px type might be too small for some, depending on the font chosen (11px Verdana and Georgia get fewer complaints than 11px Times, for instance), the monitor size and resolution, the visitor’s eyesight, the degree of foreground/background contrast, and the presence or absence of distracting backgrounds. To a person who has less than 20/20 vision, the problem might be annoying. To one who is seriously visually impaired, it might be far worse than that.

There is also the occasional CAD engineer who likes to surf the web on his 4000 x 3000 32″ workstation monitor and pepper web design mailing lists with angry letters about flyspeck-sized text. If he actually wished to solve his problem, he could use a browser that supported Text Zoom or Page Zoom. If he preferred to use IE/Windows, he could switch on its option to ignore font sizes. He could even write a user style sheet like this one: html, body {font-size: 1em !important;}

But he would rather complain about his problem than solve it in any of these ways, because for him this whole thing is a religious issue. (He also complains that the magazines he subscribes to are filled with inane coverage of celebrities and their marital problems. And he dislikes peanuts, yet he keeps eating them.) As a designer, you are responsible for your users’ problemseven this guy’s.

The Font-Size Keyword Method
Little known and scarcely ever used, CSS1 (and later, CSS2) offered seven font-size keywords intended to control text sizes without the absolutism of pixels or the inheritance, cross-platform, and user option hazards of ems and percentages. The seven keywords appear next, and their meaning will be obvious to anyone who has ever bought a T-shirt :
xx-small

x-small

small

medium

large

x-large

xx-large

Why Keywords May Beat Them and the Percentages

As mentioned earlier, when you use ems or percentages, there is always the danger that their values will multiply, resulting in text that is too small or too large. By contrast, keyword values do not compound even when the elements nest.

If is small, is small, and is small, and p lives inside div, which lives inside body, the three small values do not compound (as ems and percentages do), and the result is still legible. Moreover, the result is still small (not x-small or xx-small). Ems and percentages compound. Keyword values do not compound.

At a resolution of 1200 x 870, a single pixel looks hefty on a 22″ monitor and petite on a 17″ one. CSS considers the pixel a relative unit because monitors and resolutions vary. This is true. It is also true that 10px is 10px, from one corner of a screen to any other corner of that screen, and from one screen to the next. The pixel is always the smallest unit of a given screen, making it the atom of new-media design. Most designers and most users thus think of the pixel as an absolute unit. Unlike most other units, the pixel is familiar to all web users regardless of their level of sophistication. They know the pixel from years of watching TV.

If the CSS standard views pixels abstractly (remember that “average length of the web user’s arm” business), the makers of most browsers do not. They understand the pixel unit the way the rest of us understand it: as the smallest dot on the screen.
Thus, virtually all browsers, from the superb to the barely passable, support pixels the same way, and if you use px to specify your font sizes, you (and your users) will see what you expect in nearly every browser and on nearly every platform. As with any rule, there are exceptions: one sophisticated and vaguely troubling, and the other dumb and negligible.

When Pixels Fail in Opera
Some versions of the Opera browser consistently deliver smaller sizes than those specified. For example, if you specify 11px text, Opera 5 for Macintosh shows something closer to 10px. Håkon (pronounced How-come or Hokum) Lie (pronounced Lee) is Opera’s chief technical officer. He is also the father of CSS, to whom most designers with a lick of sense are grateful.

Some argued that Opera’s subsize handling of pixel values in its 5.0 browser for Macintosh was based on the “average arm length” abstraction. But it was just a bug.
When Pixels Fail in Netscape 4 Point Something or Other
Some versions of Netscape 4 also get pixel values wrong. In one or two incremental upgrades on one or two platforms, the old warhorse sometimes forgets how to interpret pixel units, as Grandfather sometimes forgets our names. Don’t ask me which versions of Netscape 4 get pixels wrong. Is it 4.73 for Linux/UNIX? Is it 4.79 for Windows 98? Who cares? Most versions of Netscape 4 get pixels right, even if they get practically everything else wrong.

This rare Netscape 4 pixel snafu has no basis in abstract theoretical concerns. It is simply a bugone that users can avoid by upgrading to the next incremental version of the ancient relic, or preferably to a browser released in this century. Some users won’t do it. One of them might be your boss or your client. If beating them about the head and shoulders with the nearest heavy object fails to enlighten them as to the benefits of a standards-compliant browser, start looking for a new job. (After beating your boss about the head and shoulders, you’ll have to look for a new job anyway. What were you thinking?)

Back then, several browser makers who will go nameless (like Apple) deliberately departed from the new 16px/96ppi standard on the grounds that big, horsey text was ugly. Since most users never change the default font size, if ems or percentages were used to size text, different users would see different sizes, upsetting persnickety clients and control-freak designers alike. Plus, certain old browsers I see no need to ridicule by name (including Netscape 4, IE₅, and Opera 6) botched nested percentages and ems more often than they displayed them correctly.

Given these problems, pixels appeared preferable to ems and percentages. But if you used pixels to guarantee that all users initially saw the same size text relative to their screen resolution, the text size would not scale in IE/Windows, thus creating legibility and accessibility problems for millions.

I begged all browser makers to support the standard sizeand today they do. I also (here and behind the scenes, for years) begged Microsoft to let users of IE for Windows scale text set in pixels. One out of two ain’t bad.

A Passion for Pixels

Alone among all CSS values, with a few exceptions to be discussed next, the humble pixel (px) unit works in browsers old and new, compliant and noncompliant, on any platform you care to name. 13px is 13px whether viewed in Windows, Mac OS, or Linux/UNIX. Set your text in pixels, and it will look the same in any browser or on any platform.

The benefits are not limited to fonts. Images are created in pixels. If our product shot is 200px x 200px and we use CSS to specify a left margin of 100px, we know that the size relationship of picture to margin will be 2:1, and we also know that all users will see this size relationship. Size-based relationships are a key component of grid- and rules-based designs.

For crisp layouts, pixels are a natural. If we say that our headline text is 25px tall, that our left margin is 100px, and that our body text is 11px, all users will see the same thing, although the real-world size of what they see will depend on their PC’s resolution and their monitor’s dimensions.

“Create once, publish everywhere” is the Grail of standards-based design and development. We don’t learn proper XHTML authoring to win a gold star. We do it so that our sites will work in desktop browsers, text browsers, screen readers, and handheld devicestoday, tomorrow, and 10 years from now. Likewise, we don’t use CSS exclusively for short-term rewards like reducing bandwidth to save on this month’s server costs. We do it primarily to ensure that our sites will look the same in Internet Explorer 14.0 as they do today and that unneeded presentational markup won’t impede user experience in non-CSS environments. To save breath and time, I have labeled this raison d’être of standards-based design “forward compatibility.” (I have labeled my underwear “Jeffrey,” but for a different reason.)

Standards-compliant user agents make forward compatibility possible. If the web were still viewed mainly in Netscape and Microsoft’s 4.0 browsers, forward compatibility would be unattainable by all but the most rudimentary sites. If the leading user agents that succeeded 4.0 browsers had continued to promote proprietary technologies at the expense of baseline standards, the web’s future as an open platform would be open to doubt. Thankfully, all leading and many niche browsers released within the past few years can justifiably be called “standards-compliant.” But some are more compliant than others. Coping with compliance hiccups is what this chapter is about.

Embeddable Objects: A Tale of Hubris and Revenge

When the creators of the original Mosaic and Netscape browsers first seized on the brilliant idea of allowing designers to include images in web pages, they “extended” HTML by creating an tag specifically for their browsers. The W3C did not approve. It advised web authors to use the object element instead. But millions of websites later, the tag was still going strongand support for the W3C’s element was nonexistent.

The W3C’s first act of revenge was to avoid including the

tag in any official HTML specification, in spite of the fact that hundreds of thousands of designers were using it on millions of sites. was not included in HTML 3.2. It was not added to HTML 4 or to HTML 4.01, whose sole purpose was to include commonly used tags that had been left out of HTML 4. And because XHTML 1.0 was based on HTML 4.01, was not part of XHTML, either. Therefore, any site that used could not and still cannot validate as HTML or XHTML.
That is correct. You read that right. Millions of sites that embed multimedia cannot validate against a W3C spec because the W3C never deigned to recognize the

element.
A Standard Size at Last
In an effort to transcend platform differences, the makers of Netscape and Microsoft’s browsers and Mozilla put their heads together in late 1999 and decided to standardize on a default font-size setting of 16px/96ppi across platforms. By putting all platforms on the same page, as it were, browser makers and users could avoid the problems of cross-platform size differences and cruelly useless, illegible text.
The 16px/96ppi Font-Size Standard
On a W3C mailing list in 1998, the plucky Todd Fahrner puckishly proposed standardizing on a 16px default per Windows usage. His recommendation was adopted by all leading browser makers in the year 2000. Although Fahrner’s concerns were practical in nature (he wanted to ensure that type could be read online), in the quotation that follows, he refers to something that might strike you as bizarre.
The framers of CSS1 were bound to a pet abstraction wherein the “average” length of a web user’s arm was essential to defining the size of a pixel. No, really. Anyway, in advancing his idea about a standardized cross-platform font size, Fahrner was careful to cover the all-important arm’s length issue along with more pedestrian matters like usability. He wrote:
Since before Mosaic, the default font-size value in all major browsers has been set at 12pt. I propose redefining the default as 16px…. The current default of 12pt rasterizes very differently across platforms. On Macs, it rasterizes into 12px (logical res fixed at 72ppi). On Wintel PCs, it rasterizes by default into 16px (logical res defaults to 96ppi). …All scalable font-size values… operate relative to this inconsistent base rasterization. For a designer, this means that the only way to suggest a [consistent cross-platform] font size is to use CSS pixel units, which are not user-scalable, and are thus not optimally user-friendly/portable…
The appropriate corrective measure… is for Mac (and X11?) browsers to break with tradition and ship with the default value of “medium” text set at 16px, instead of 12pt. This should of course remain subject to user adjustment, but a consistent initial value will at least make the use of scalable font-size values less problematic for designers, as any variance from the default will be due to express user preference rather than capricious legacy OS differences.
If designers tend to believe that 16px is too large as a base, why suggest it as the default?
One reason is pure expediency. The Mac is a smallish minority platform, though very strongly represented in the web design field. (I use a Mac!) It is unrealistic to expect that Windows/X11 browsers will change their defaults to match the Mac’s rather quaint limitation to 72ppi logical resolution.
The 1996 CSS1 standard suggests a 1/90″ value for a “reference pixel,” extrapolated from a visual angle of 0.0227 degrees visual angle at arm’s length. [User agents] are expected to scale pixels appropriately if the physical resolution is known to vary significantly from this value. A 1/90″ reference pixel would suggest a rasterization of 12pt into 15px, rather than 16. 15 is, of course, much closer to 16 than to 12, however. Because no OS/UA currently assumes a 90ppi logical resolution (nor implements pixel-scaling) … the reference pixel value should be amended to 1/96″.
It’s simple to preserve the suggested 0.0227 degrees visual angle by giving the reference user a longer arm’s length.
Designers think that 16px is too large simply because they are used to the 12px base size of their Macs. Readability is 9/10ths familiarity.
Two years later, the first generation of significantly standards-compliant browsers embraced Fahrner’s recommendation. In Internet Explorer, Netscape, and Mozilla, on both the Windows and Macintosh platforms, the default text size became 16px/96ppi, and increased legibility was enjoyed throughout the globe (except when some users changed it back).
Fahrner’s efforts eventually led the W3C to agree to a standard reference pixel size related to the 16px/96ppi concept, as seen in the CSS 2.1 working draft. In the excerpt that follows, you’ll note that the W3C remains quite concerned about the average length of a reader’s arm. We should be grateful they’re only talking about the length of an arm:
It is recommended that the reference pixel be the visual angle of one pixel on a device with a pixel density of 96dpi and a distance from the reader of an arm’s length. For a nominal arm’s length of 28 inches, the visual angle is therefore about 0.0213 degrees. (CSS 2.1 Working Draft, )
While the standard reference pixel would seem to clear the way for a W3C standard user default size, the two are not officially related. The W3C has spoken to the first issue, but not to the second.
Netscape 6+, Mozilla, IE5+/Macintosh, and IE/Windows offered all users the same default font-size setting. As long as the user did not change her preferences, points, ems, percentages, and font-size keywords would work the same way across platforms and no user would be needlessly hurt because of a designer or developer’s ignorance about platform differences. There were still bugs and inheritance problems in some browsers’ implementation of percentages and ems (more about those problems a few pages later), but the primary hurdle had been cleared.
Alas, browser makers don’t explain why they do what they do, and web users don’t study design issues (and why would they?). The benefit of a standard size temporarily evaporated as some users (and many designers) missed the point literally.