The Pitfalls of Style

Web Review
December 1997

This month, let's take a look at a few common traps in which beginning CSS1 authors often find themselves ensared... and then find out how to escape them, when possible, or at least find out how the traps got there in the first place. Remember, these are the frontier days of style sheets, where we don't yet have all the comforts of a well-supported language. So step lively, pardner-- we're about to see the rough side of being stylish.

Color, Color Everywhere

Most of you, being experienced Web authors, have at some point in your lives set the color of your document text using the text attribute to the BODY tag, like this: 

   <BODY text="purple;">

Now you can avoid that by using CSS1. To get the same effect, you can declare this in a style sheet: 

   BODY {color: purple;}

So there we have it-- everything one needs for a page with purple text.

And, as it happens, purple everything else. Including horizontal rules, which will lose their pretty engraved effect and become flat, unshaded, purple lines. Now, this might be okay in some cases, but mostly it's just annoying. How can we beat this?

Well, I'd like to tell you about a quick, easy way to get around this problem. Yessir, I certainly would. Only I can't, because at this point, there is no easy way around it. The only way to get all of your text purple, but leave your HRs shaded and not purple, is to set the color for every block-level element you use in your document, and not set a color for the BODY. It would go something like this: 

   H1, H2, H3, H4, H5, P, UL, OL, PRE, BLOCKQUOTE, TABLE {color: purple;}

And that's how you get around it. Not exactly ideal, but sadly, we have no other choice-- for now. Stay tuned, though...

The Incredible Shrinking Text!

This problem is closely related to the one we just talked about. Once again, setting properties for BODY is revealed to be a dangerous business, but there are ways to cope.

Getting into this trap is fairly easy. All you have to do is declare the following: 

   <STYLE type="text/css">
    BODY {font: 12pt serif;}
   </STYLE>

It looks so harmless, doesn't it? After all, it only specifies a font size and family-- not even bothering with a specific font. Ah, but looks are often deceiving. This simple little style sheet can wreck a lot of things. What will happen is that in some browsers, all text will be 12-point and in a serif font. That includes text in headings, teletype text, preformatted text, text enclosed in FONT tags, and so on. Absolutely everything will be 12 points in size, and in a serif font. Why does this happen? Because font is inherited, so all elements of the BODY tag (and that should be all of them) will inherit these settings.

There are two ways to beat this. The first is to use the style sheet above and add appropriate declarations for various elements, thus: 

   <STYLE type="text/css">
    BODY {font: 12pt serif;}
    H1 {font-size: 18pt;}
    H2 {font-size: 16pt;}
    H3 {font-size: 14pt;}
    PRE, TT, CODE {font: 10pt monospace;}
   </STYLE>

However, this is not necessarily a good idea, because points aren't always the best way to set font size. (In fact, there is a healthy debate over whether they're ever a good way to set font size, but I'll leave that for some other time.)

The other solution is much better: use the absolute-size keywords for font-size. These are xx-small, x-small, small, medium, large, x-large, and xx-large. Thus you could use the style sheet: 

   <STYLE type="text/css">
    BODY {font: medium serif;}
    H1 {font-size: xx-large;}
    H2 {font-size: x-large;}
    H3 {font-size: large;}
    PRE, TT, CODE {font: medium monospace;}
   </STYLE>

Either way requires a certain amount of annoyance and effort, so it pretty much boils down to picking your favorite poison. Or, if you want to be really bold, choosing whichever method is more appropriate to the task at hand.

Dropping Drop-Caps

If you've looked through the W3C CSS1 specification, you probably got pretty excited about the pseudo-elements. One of the coolest ones is :first-letter, which lets you define display rules for the first letter of an element; these rules can differ from those for the rest of the element. Consider this: 

   P {font: 12pt serif; color: black;}
   P:first-letter {font: 200% serif; color: navy; float: left;}

This should make the first letter of each paragraph twice the size of other text, floated to the left, and navy blue. In other words, it's a drop-cap.

But, wouldn't you know it, none of the browsers out there support :first-letter, so it haunts us like a lonely spirit, wrecking the mirrors and dripping blood on the walls. How to exorcise this demon? The best way to compensate is to use the SPAN tag, like this: 

   <STYLE type="text/css">
    P {font: 12pt serif; color: black;}
    .dropcap {font: 200% serif; color: navy; float: left;}
   </STYLE>

   <P><SPAN class="dropcap">T</SPAN>his is the first sentence
   of the paragraph.</P>

It's a little less elegant, but it gets the job done. Well, as much as is possible, actually. Here's the problem: This will only work in Netscape Navigator 4.x, because that's the only browser which supports floating text elements, including those within the <SPAN> tag (see figure 1 below).

Drop cap style as viewed in Nav 4.04
Figure 1: Drop cap style as viewed in Netscape Navigator 4.04. This is the proper way to render a drop cap.

And people who are using IE will see the floated text element aligned on the baseline of the first line of type, rather than being "set" as a drop-cap (see figure 2 below).

Drop cap style as viewed in IE 4.0b1
Figure 2: Drop cap style as viewed in Microsoft Internet Explorer 4.0b1. Notice how the "T" rests on the baseline rather than floating to the left of the paragraph.

Thus, many users won't see the "drop" effect, although the letter should be larger and navy-colored (as in the above examples). So not only do we have first-letter unsupported, but the only reasonable way around it isn't really supported either. Did I mention that things are still a little rough around the edges with CSS? Having the Netscape and Microsoft browsers render styles in the same manner would certainly make life easier on Web developers who are trying to add style sheets to their pages. (Plus, not to mention the amount of time it will save us from having to go back and forth between browsers to make sure something works properly.)

Conclusion

Well, that should give you a good start at getting around some of the common problems with style sheets. Sometimes, getting the right style is a matter of tip-toeing around the conflicts one finds in style sheets to get the look you're after.

This is, of course, what happens when there isn't much in the way of consistent support among Web browsers. Until the browsers advance and add more support for CSS, Web developers will have to resort to "trial and error" methods of styling their pages.