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.