CSS Highlights

Assuming that you’ve marked up the structure of your document with many well-meaning elements, we’ll now turn to CSS to transform your well-organized outline into a multicolumned, colorful beauty. However, this is just the tip of the iceberg; of course, we focus on issues related to universal design. If you are new to CSS, check out a comprehensive CSS reference (anything by Eric Meyer or Christopher Schmitt).

Liquid Layout

One of the first concepts to introduce is units of measure, as they are a key component in designing a liquid layout. Early web designers were making the transition from print design to the Web. In print, you have fixed layouts that are precisely defined and static—they are “pixel-perfect.” But those designers had no control over which browser someone used, or the size of the browser window, or the size of the text, which meant that their pixel-perfect designs weren’t very perfect.

As HTML and CSS evolved, designers realized they could create designs that would reflow to accommodate browser version, window size, and text characteristics. Instead of seeing everything as absolutely positioned, designers started thinking in terms of relative positions.

Thus, there are three ways to specify length: relative units, absolute units, and percentages. Here are the definitions from the CSS2.1 specification:[17]


Relative length units specify a length relative to another length property. Style sheets that use relative units will more easily scale from one medium to another (e.g., from a computer display to a laser printer).

Relative units are:

  • em: the ‘font-size’ of the relevant font

  • ex: the ‘x-height’ of the relevant font

  • px: pixels, relative to the viewing device

Absolute length units are only useful when the physical properties of the output medium are known.

The absolute units are:

  • in: inches—1 inch is equal to 2.54 centimeters.

  • cm: centimeters

  • mm: millimeters

  • pt: points—the points used by CSS 2.1 are equal to 1/72nd of an inch.

  • pc: picas—1 pica is equal to 12 points.

Percentage values are always relative to another value[.]

 --CSS 2.1 Specification, W3C Recommendation

The most commonly used units are em, px, and percentages, and they are all relative to something else (whether it be another length property or another element) and reflow differently.

Text Size

In terms of accessibility to users with disabilities, text size has become somewhat less of a problem recently. Firefox 3 and Internet Explorer 7 each adopted full-page zoom, a feature that’s been in the Opera browser for years. This kind of zooming increases the size of every element on the page—text, images, tables, even Flash objects—in contrast to the old model, on which only the text itself is magnified. MobileSafari uses this feature most often; it’s how users pinch and expand documents on the iPhone.

Of course, this shift isn’t necessarily always an improvement. For example, if you’re a user who wants text to be twice as large, full-page zoom also doubles the column width, and depending on the kind of display, that could require users to scroll left to right, line by line through long passages of text. Thus, it is still important to set your font sizes using relative units so that users can override them without having to resort to zooming.


If you have used semantic HTML, there’s not much that using CSS will do to break it. We won’t say much about positioning here, but we do have a lot to say about it and its effects in Chapter 8.


A great use of CSS’s ability to include images is background images: they are decorative and don’t need a text equivalent. However, using background images for images that convey important information is not a good idea unless that information is available in the text of the page. General rule: if it’s purely decorative, it’s cool to use CSS to include it; if the image conveys important information, use the img element with an alt attribute (see Chapter 3 for information about using the alt attribute).

Text Versus Images of Text

Web content is reaching a turning point with respect to the treatment of text. In fact, there are two major changes that will have a near-term impact on text on the Web: full-page zoom and web fonts. During this transition, though, there will still be millions of users who aren’t up on the new tech, so it’s important to look at what works now, and determine for yourself how to write your content so that you can transition without stress.

What works now

In the Firefox 2/IE 6 era, the zoom function of the browser caused the fonts to resize but not the remainder of the document’s structure. The result was text that was often smashed together or short lines of chunky text in increasingly absurd layouts. To address this, it was recommended to design documents using CSS rather than tables and to use relative CSS units so that the document would resize along with (or around) the larger fonts. On the other hand, full-page zoom increases the entire page’s dimensions, including images, tables—you name it. While we still emphasize using CSS for layout, it’s not strictly necessary for full-page zoom. CSS-based layouts will, however, come in handy when your page is transformed in mobile browsers.

Web fonts are another story. Due to a couple of unproductive attempts at web fontography, the Web has been limited to a small subset of the fonts currently available in TrueType, OpenType, or Adobe Type 1 format, to wit:

  • Times New Roman

  • Helvetica (or Arial)

  • Courier (or Courier New)

  • Verdana

  • Tahoma

  • Georgia

  • Trebuchet MS

  • Impact

In other words, this is the limited set of fonts that are common to both Windows and Mac operating systems. However, many *nix (Unix and Linux) machines do not have these fonts.

A lot of people haven’t been very happy with this, and there have been many, many different attempts at trying to bridge that gap. Most of these were image replacement schemes that used CSS tricks to replace semantic HTML headings with images, ostensibly offering the best of both worlds. One of the first to take hold was Fahrner Image Replacement (FIR). The idea, named after creator Todd Fahrner, hid the heading text and replaced it with an image with the bitmapped text. Unfortunately, what was good for semanticists was not necessarily good for universal design. Namely, using FIR, screen readers no longer read the heading text at all.

Various other alternatives popped up, with various positive and negative effects. With image replacement, one big downside is that the images all have to be preauthored and sized to the area they’re supposed to fill, making the approach fragile and time-consuming. With that in mind, Mike Davidson adapted a technique created by Shaun Inman, and Scalable Inman Flash Replacement (sIFR) was born.

The principal advantage of sIFR over image replacement schemes is that any heading can be rendered in nearly any antialiased font you like. It takes some configuring, with a separate style sheet and a JavaScript file you have to customize and embed, but once that’s done, you can set, for example, every H4 to appear in red Trajan Pro. Better, if your users don’t have Flash (such as, say, iPhone users), the heading itself degrades gracefully.

Alas, sIFR has its limitations as well. Like image replacement, when you select a span of text that includes a sIFR heading, the heading text won’t be included. You’ll need a copy of Flash and the font you want. And you don’t want to use it for more than a couple headers per page, or you risk dramatically increasing the load time. That said, it works with screen readers, it’s pretty, it’s reasonably simple, and it’s much more fun than sitting in Photoshop, churning out GIFs.

But still, when there’s a better way, use it.

For examples, documentation, and a support forum for the sIFR technique, read Mike Davidson’s blog “sIFR 2.0: Rich Accessible Typography for the Masses” at http://www.mikeindustries.com/blog/sifr/.

Web fonts

One approach to the limited number of fonts on the Web has been floating around almost as long as the Web itself. As early as 1997—the golden age of the browser wars—embedded or downloadable fonts saw implementations in Internet Explorer 4 and Netscape 4. Naturally, as with much of the ingenuity of that era, they were incompatible with each other: Microsoft based its embedded fonts on OpenType, while Netscape partnered with Bitstream. For a long time, nothing happened, and eventually the wind was gone from the web fonts’ sails.

Today, thanks at least in part to a new CSS-support arms race, a new round of web font mania has arrived. Opera Software has announced support for the web fonts module of CSS3, published as a working draft in 2002 by the W3C. The developers of WebKit, from which Safari and Konqueror are drawn, have also announced they’re working on web fonts, and Microsoft is rumored to be in the mix as well with Internet Explorer 8.

You may think that web fonts will finally make your life easier. But they won’t. Especially when you’re thinking about increasing your audience. Most mobile devices won’t ever bother to process embedded fonts in CSS. It’s simply too much to ask of devices with limited bandwidth and processing power. Using arbitrary fonts has implications for readability as well, given that not all fonts are created equal, and many designers, to put it lightly, are not known for their restraint.

An even bigger problem, though, is internationalization. If your style sheet is ever going to be used with content in several languages, you will need to ensure that the fonts you select contain glyphs in all of those scripts (Japanese, simplified and traditional Chinese, Hebrew, Arabic, Indic scripts, and so on). One advantage of local fonts is that these issues have long ago been sorted out. Issuing just-in-time font selections will certainly expose the poor support in many otherwise very pretty fonts for scripts other than Latin.

Get Universal Design for Web Applications now with the O’Reilly learning platform.

O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.