elements of style

March, 2001.
By Molly E. Holzschlag. (Link to original article.)

There are few things as sweet as a promise kept, and nothing so bitter as one that isn't. In 1996, style sheets promised us incredible opportunities for control over Web document presentation. But that promise has been only partially fulfilled, making our relationship with style sheets bittersweet.

Style sheets are advantageous in that they let you manage, update, and change large sites easily, and elegantly control visual effects. Documents become more streamlined and manageable when designers effectively separate presentation from Web markup.

While style sheets have expanded to include detailed syntax for broad presentation options, support is often limited, buggy, or sometimes completely nonexistent within certain versions of popular Web browsers.

So if you're frustrated with style sheets, you're not alone. Despite advancements in browser support—especially with the impressive support the recent distribution of Netscape 6 provides—working with style sheets remains a challenge to even the most adept Web markup authors.

Bad rap

Part of the problem is that style sheets have gotten a bad rap. While frustrating to most Web designers and developers, style sheets also suffer from poor marketing. This is pretty typical of complex or emerging technologies, and it's a serious problem because it makes people leery of trying them. XHTML is a good example: Poor marketing equals a misunderstood tool.

Even the most sophisticated developer is hesitant to wade through convoluted W3C documents to unravel which markup technologies actually work. It's a challenge that only the very brave or very patient are willing to tackle.

On an academic note, I was rather shocked to read a recent email from a reader whose son was taking an HTML course at a major university. The instructor apparently told this woman's son that style sheets were dead, and the woman asked if I could confirm it.

Let me instead issue a firm denial: CSS is not only alive and well, it's living vibrantly. Its uses are increasing in scope, and it works with HTML, XHTML, and XML applications to offer presentation options for a growing range of user agents.

It's bad enough that W3C documents are so difficult to interpret. That an instructor is spreading erroneous information about style sheets in the educational realm is very disconcerting.

Like I said, bad rap

Ultimately, the real question for professional designers and developers is how to effectively determine whether style's advantages outweigh the risks—or whether the sweetness, if you will, overpowers the bitterness.

What's your style?

I have a four-step method that I use to determine whether a project could benefit from CSS. Feel free to modify this list to your unique needs.

1. Focus on your audience. My long-time readers are groaning at this point because they've seen my "audience first" mantra one too many times. I realize that I'm mostly preaching to a harmonious choir, but until I stop having to explain to working professionals that "know your audience" is the foundation of any effective communication—be it verbal or written—I'm going to keep a-preachin.'

Knowing audience specifics is critical to determining whether a particular style is an appropriate choice. Who are your site visitors, or who will they be? What kinds of browsers are they using? Are they young people with great eyesight, or older folks, potentially with vision problems? Should you decide to style your document, having some demographics will help you make better choices about how to serve your audience most effectively.

I've tracked the statistics on my personal Web site, Molly.com, for some years now. Because my visitors are often people who read my articles and books, they tend to be quite Web-savvy, and their technology stats prove that. Knowing this about my audience, I decided that aggressive use of style sheets was, in fact, a good choice for my site. In prior years, it was still questionable. Tracking my audience told me precisely when I could contemplate using style sheets.

2. Determine the project's scope. Next, you'll need a very complete understanding of your project's scope. Style is most effective when it gives you and your production team an empowering and enabling tool.

How many documents comprise the site? If it's only 10, style sheets can certainly be a helpful option. What if it's 100, or 1000, or 10,000, or more? External style sheets are the single most powerful way to update, change, and add style to all linked documents instantaneously. A single style sheet controlling many documents is the best example I've found of style living up to its promise.

During the recent restructuring of Web Techniques' sister property, WebReview.com, I became intimately familiar with this power. Using a master style sheet for the site lets us make certain changes instantaneously to thousands of documents. It's a blessing, saving countless hours of human effort, and lots of money, too.

3. Choose a markup. Depending upon what your site content covers, you may choose to use style, forgo it altogether, or use it combined with transitional HTML 4.0 or XHTML 1.0 elements to accomplish your goals. In some cases, you may be using CSS to apply presentation rules to XML documents. Knowing which client-side markup you're going to employ will help you determine how to deploy your style.

Transitional HTML 4.0 and XHTML 1.0 documents are natural and easy mates with CSS. With XHTML and other XML applications, you may wish to use CSS, or examine other style sheet options, like XSL/XSLT.

4. Pinpoint presentation needs. Before you dive headlong into working with style sheets, assess the extent of presentation styles necessary to accomplish your design. If it's a matter of using CSS to manage type versus the positioning of objects on a page, you'll likely find that the typographic style options are better supported for wide audiences, and therefore a rational choice in many instances. If, however, your goal is to use style for positioning, you must revisit step 1 to ensure that your audience will be able to support it adequately.

Recommendations

So you've made your decision. If you're going to employ style, you'll want to be in control, and gaining the upper hand takes a bit of strategy. First, it's good to know which style options are best and which are useless. Then, you'll want to avoid certain pitfalls.

I have some general recommendations on using style sheets safely. However, please don't let these recommendations dissuade you from trying new things or using approaches you've already found acceptable for your work.

What's more, I'm breaking my recommendations into three sections: version, typography and color, and positioning. This is a pared-down version of what's really available in style sheets, but these are the areas where broad generalizations work best.

Version.

The version of CSS that you choose greatly impacts its interoperability. CSS1 is much more widely supported. CSS2 is gaining ground, but much of it is limited in its availability at best.

So for more wide-spread use, choose CSS1 and examine aspects of CSS2 that might be applicable to your needs while still providing a best-case scenario for your audience.

Typography and color.

Most of the available type style properties are interoperable. I highly recommend stripping out those pesky font tags and using style sheets for your typographic needs in almost all transitional HTML 4.0 and XHTML 1.0 documents for contemporary audiences. But, as always, there may be mitigating factors with your audience, so revisit your demographic data to make certain you're getting the best coverage. Color is also quite stable. As a result, you can confidently use type and color via CSS.

A helpful testing trick is to remove the style and view the page. Does it degrade gracefully enough to be acceptable? If so, you'll be fine.

Positioning.

This is much more difficult to accomplish with style sheets. They offer less interoperability overall, and it's harder to mix-and-match positioning with table grids to achieve a sophisticated and interoperable layout.

If you're going to use positioning, be sure your audience is small and specialized. Your visitors will need browsers capable of rendering style positioning appropriately.

Pitfalls

Let's say you've decided to use style for a general audience. If you've planned according to the methods set forth in this column, you've decided to use CSS1 and possibly some options from CSS2. You're focusing on typography and color rather than object positioning. Look closer at a few examples of the properties you'll want to watch out for.

The list item font quirk.

As I mentioned, working with fonts is pretty simple. You can apply fonts easily using standard or class selectors. Also, the most elegant way to streamline your markup is to dump those pesky font tags. There are, however, a few places where the application of fonts to certain elements is quirky.

One quirk is in the list item (li) element. In Netscape 4 versions, for example, fonts won't render properly despite the fact that you've created a rule for the li selector.

Example 1 shows a sample style rule for the li element. Figure 1 shows how the list item style has properly rendered in Internet Explorer. In Figure 2, this style hasn't rendered appropriately in Netscape 4.7 for Windows. Instead, the li content reverts to default fonts.

In a case like this, you can leave the fonts alone if they don't bother you too much. But if you're a stickler for consistency, you can add font tags to your list items to apply the proper font face.

Example 1. A sample style rule for the li element.

li {
font-family: verdana, helvetica, arial, sans-serif;
font-weight: normal;
font-style: normal;
color: #000000;
text-decoration: none;
}

Figure 1. Internet Explorer has properly applied the style rule for the list items in this example.

Figure 2. Without proper support, Netscape Navigator 4.7 renders the list items in the default browser font.

Line height, alignment, justification.

Line height, known as "leading" (pronounced ledding) to designers, is the physical space between each line of text. Controlling line height gives your text different looks, adding interest to headers and captions—even body text if you so desire. But line height isn't consistent in all browsers; it can even cause a design that looks attractive in one browser to render as an unsightly mess in another. So use line height with caution.

Alignment is another fairly solid option with CSS. The support for alignment to the left, right, and center is good. But justification is one potential quirk. The justify value won't render in many browsers. Fortunately, the default will be standard left justification—anything you've justified simply appears as left justified in browsers that don't support the feature.

Links.

Using style sheets to declare management of link colors should be more explicit in its support, but it's not. Adding link colors such as the link, active, and visited works well in IE 4.x and later browsers for both Windows and the Mac. The main problem is with Netscape Navigator for Windows and Mac at 4.x and earlier, where active and visited link colors aren't supported.

The workaround here is to use link colors in the body tag of your document as well as using style sheets.

There are, of course, countless examples of quirks, and I can only introduce a few of the more common ones here. For a comprehensive look at style support within browsers, please see the WebReview.com "Style Reference Guide," edited by Eric A. Meyer (available at style.webreview.com).

Find your style

If you've hesitated to embrace style sheets, I hope you'll take the plunge. While their promise hasn't yet been fulfilled, using a few logical techniques, you can create interoperable documents with CSS. I believe we're moving toward a time when use of style sheets will be much more fully realized than before—and as a result—empower us, as Web authors, to design and manage our documents more efficiently.