CSS IN THE TRENCHES, Part Two

Advanced Features & Incompatibilities

REVIEW

Style Sheets (CSS) are an important Web standard, allowing designers to specify the font family, size, margins, and leading of type on the Web; permitting designers to create advanced Web layouts without abusing HTML; and enabling Web designers, HTML practitioners, and programmers to separate design elements (presentation) from content.

The ability to separate presentation from content empowers Web designers to create attractive sites without excluding visitors who cannot use graphical browsers, and paves the way for the future expansion of the Web beyond the desktop computer and onto a variety of hand-held and other Web devices.

Fortunately, CSS is easy to learn and use.

Unfortunately, full support for CSS has been a long time coming. Even though the CSS Level 1 standard was finalized in 1996, the first browser to fully support it did not appear until the year 2000 (Internet Explorer 5, Macintosh Edition). Netscape Navigator 6, unreleased as of this writing, will also fully support CSS Level 1. And Opera Software's Opera browser will support most of it. Sadly, these browsers are used by a minority. Internet Explorer 5 for Windows, used by the majority, does not fully support Style Sheets, and may not do so before the release of IE6 (if then). And Netscape Navigator 4, still used by tens of millions, does such a poor job of handling Style Sheets that it has been known to crash upon encountering them.

Article:

"The Day the Browser Died"

Faced with these inconsistencies, many Web designers have avoided using CSS altogether. This is not necessary or recommended, however. Below, we will discuss methods of using CSS safely and highlight problem areas to avoid.

CSS PROBLEM AREAS

Web Review publishes useful information on CSS problem areas and "safe" uses of CSS. Take some time to look over the following:

Web Review Compatibility Charts.

Of special note:

The Master List

"The mother of all CSS (Cascading Style Sheet) charts," listing every aspect of the CSS spec and identifying how well it is supported by Netscape 4.x and Internet Explorer 3.x, 4.x, and 5.x for both Macintosh and Windows 95, and Opera 3.6 for Windows

Safe CSS Properties

These charts show which CSS properties are supported in various browsers. Web designers may draw their own conclusions about which properties to use, and which to avoid, based on the browsers used to visit their clients' sites, or on industry reports which attempt to show which browsers are used, and by how many people.

These charts portray a fragmented browser space, where it appears that few CSS properties may be safely used. And it is fair to say that the full power of Cascading Style Sheets will elude Web designers until Internet Explorer, Netscape Navigator, and Opera completely support all CSS properties on all computing platforms. Even then, Web designers will have to wait until the majority of Web users have had sufficient time to upgrade to these standards-compliant browsers, a process that usually takes up to 18 months.

In the meantime, however, Web designers can begin using CSS conservatively, by following the "No-Fault CSS" Plan outlined in A List Apart. We will summarize the plan below, and then provide links for further reading.

NO-FAULT CSS

The "No-Fault CSS" Plan advises Web designers to use those parts of the standard which are supported in most browsers. This generally means using CSS (instead of FONT FACE and FONT SIZE tags) to specify Web typography in terms of font family, size, and leading, and avoiding the use of CSS as a full-fledged layout tool until it is properly supported in all browsers. Even that plan can snag on some "gotchas," but we will point those out as well.

CSS AND LAYOUT

One of the great strengths of CSS is its ability to position elements on a Web page. Elements may be positioned by exact pixel coordinates (400 pixels from the top, 32 pixels from the left, for example). They may be positioned relatively to each other. They may be positioned via percentages, permitting Web designers to easily set up "liquid" layouts, as previously discussed.

Unfortunately, CSS positioning is not supported in IE3, and is buggily supported in Netscape Navigator 4 (ie., it can cause the browser to crash). Therefore, Web designers are advised to continue using HTML tables for layout purposes, and to avoid CSS layouts until we have better browsers. Web pages laid out with HTML tables will work in Netscape 1, 2, 3, 4, and 6; in IE 2, 3, 4, and 5; and in all other graphical browsers.

This means that Web designers cannot yet separate form from content, and that they will continue to face difficulties in creating Web sites that work well outside the traditional desktop computer-based browser. But in the trenches, where work gets done, it also means that they can create sites that work for their clients and their clients' audiences.

CSS AND TYPOGRAPHY

By using CSS instead of FONT FACE and FONT SIZE tags, Web designers may specify the design of typography on Web pages, including recommended font families, sizes, colors, background colors, and leading (line-height). This practice will not only provide access to functions which FONT FACE and FONT SIZE tags cannot offer (leading, background colors). It will also:

  1. Conserve bandwidth by replacing hundreds or even thousands of FONT FACE and FONT SIZE tags with a single line of code that resides on a separate Style Sheet.
  2. Reduce the time necessary to implement a site, since the Web designer or the HTML practitioner need not type unnecessary tags for every headline and paragraph.
  3. Make it easier for the Web designer to update the site's look and feel. Doing so is as easy as replacing a single line of code on a separate Style Sheet document, instead of hunting through every page of the Web site in search of FONT FACE and FONT SIZE tags.
  4. Bring the site closer into line with current World Wide Web Consortium (W3C) recommendations.
  5. Make it easier to further streamline and update the code when additional Web standards are supported, and the client is ready to begin employing powerful standards such as XML and the Document Object Model.

There are, however, a few problems to watch out for, even when following this relatively conservative approach to using CSS.

FONT SIZE CHALLENGES

CSS allows Web designers to specify the size of typography on Web pages. As shown below, font sizes may be indicated using any of the following: points, pixels, absolute keywords, relative keywords, length units, and percentage units.

H1 {font-size: 14pt}

H1 {font-size: 14px}

H1 {font-size: x-large}

H1 {font-size: larger}

H1 {font-size: 1.5 em}

H1 {font-size: 125%}

Points. This is the terminology with which designers are most familiar, from their years of creating print layouts in Quark Xpress and similar programs. Unfortunately, points are meaningless on the Web. Due to platform and resolution differences, 14pt could be large or small. Not recommended.

Pixels. Though screen resolutions vary, a pixel is always equal to a pixel. Pixels are the only reliable means of sizing typography if the designer absolutely must control the size of type on the Web page. Unfortunately, this practice may cause problems for some readers. For instance, if the designer has specified ten pixel type:

  1. The visually impaired may have difficulty reading the type. This is not a problem in IE5/Mac, which allows users to resize type at their discretion. Most other browsers, however, do not allow the user to resize CSS type specified in pixels. Thus, there is a serious usability issue involved in this practice.
  1. On some computing platforms, notably Linux, if the user does not have the font specified, at the exact size specified, the type will display jaggedly, and be unreadable. The only safe sizes for Linux users appear to be 11px, 12px, and 14px. This is extremely limiting for Web designers.

Absolute size keywords. There are seven absolute size keywords in CSS.

xx-small

x-small

small

medium

large

x-large

xx-large

If implemented correctly and uniformly, they would allow designers to specify approximate sizes without running into either of the usability problems associated with pixels (above). For that reason, the W3C recommends their use. Unfortunately, absolute size keywords are unusable in current browsers, since only IE5/Mac renders them correctly. Netscape 4 ignores them. Netscape 4.5 and IE3 render them at illegible sizes. (For instance, Netscape 4.5 and IE3 render xx-small at 6 pixels, which is 3 pixels below the threshold of readability). IE renders them correctly in IE5/Mac, and incorrectly in IE5/Windows, where they are all too large. (In IE5/Windows, small is displayed as medium, medium is displayed as large, and so on.) Sadly, then, Web designers cannot follow W3C recommendations and use absolute size keywords until the browsers shape up.

Relative keywords are limited to two: smaller and larger. These in turn refer to the size of the parent element. For example, consider the example below, in which the BODY is 12px, and BOLD is "larger."

<HTML>
<STYLE TYPE="text/css">

<!--

BODY {font: 12px verdana, arial, geneva;}

B {font-weight: bold; font-size: larger;}

-->

</STYLE>

Bold type would be 14 px tall in this example, because 14px is one "notch" up from 12px. Like absolute size keywords, relative keywords are ignored or bungled in some popular browsers (Explorer 3 ignores them, as does Navigator 4 for the Mac.) And even if they worked correctly, they would be insufficient for the needs of most Web designers and their clients.

Length units include the following:

  1. em (a unit of distance equal to the point size of a font. In 14-point type, an em is 14pts wide.)
  1. ex (X-height refers to the height of lowercase letters.)

When used with the font-size property, em and ex units refer to the font size of the parent element.

<HTML>
<STYLE TYPE="text/css">

<!--

BODY {font: 12px verdana, arial, geneva;}

B {font-weight: bold; font-size: 2em;}

-->

</STYLE>

In the example above, BOLD would be 24px tall, or 2em (two times the font size of the parent element, which is the BODY tag). In theory, a Web designer could create a design, using em or ex units, where all elements were sized relative to each other. This would avoid the usability problems associated with pixels. Unfortunately, the browsers make this impossible for the time being. Netscape 4 ignores em and ex units. IE3 treats em units as pixels. Thus, 2em is mis-translated as 2 pixels tall (!). Not recommended.

Percentage units, like length units and relative keywords, refer to the size of the parent element.

<HTML>
<STYLE TYPE="text/css">

<!--

BODY {font: 12px verdana, arial, geneva;}

B {font-weight: bold; font-size: 200%;}

-->

</STYLE>

In the example above, BOLD would be 24px tall, or 200% of the font size of the parent element, which is the BODY tag. In theory, a Web designer could create a design, using percentages, and avoid the usability problems associated with pixels. Uh-uh. Netscape 4 for Mac ignores percentage values entirely. Netscape 4 for Windows treats percentages as pixels. (Thus, 200% is stupidly translated as 200 pixels.) And IE3 drops the ball by sizing percentages relative to the user's default font size, rather than to the parent element. Sadly, not recommended.

CONCLUSION: In the trenches, where work gets done, Web designers will continue to be limited to using pixels in their style sheets - with all the usability issues associated with that practice - until standards-compliant browsers exist and are widely used.

LEADING AND IMAGE OVERLAP

Leading - the ability to specify an exact or relative amount of vertical white space between lines of text - is one of the greatest attractions of CSS. Prior to style sheets, Web designers had to manually insert invisible spacer pixel gifs between lines of HTML text in order to simulate leading; or they had to set type in Illustrator or Photoshop, and export it as a gif image rather than actual HTML text. Both practices yoked content to presentation, wasted bandwidth, and presented usability problems. Displays based on invisible spacer pixel gifs could break in some browsers. Text gifs were useless to the visually impaired and other users of text-based browsers, and prevented search engines from indexing important site content.

The CSS line-height property solves all those problems, but it can lead to new problems, particularly in older browsers whose support for CSS is largely theoretical. For instance, in the example below, if CSS line-height is specified for the <P> tag, the image will float on top of the text in both IE3 and early versions of Navigator 4:

<p<img src="dog.gif" width="100" height="100" alt="My dog, Pookie." Title="Pookie is a friendly mutt." align="left">My dog Pookie liked this text so much, he decided to sit on it in IE3 and Navigator 4.</p>

The solution to image overlap is to keep images outside of paragraphs and <div> tags. Unfortunately, doing so brings up yet another problem in Netscape Navigator 4:

<img src="dog.gif" width="100" height="100" alt="My dog, Pookie." Title="Pookie is a friendly mutt." align="left">

<p>My dog Pookie liked this text so much, he decided to shove it to the right in its own little column in Navigator 4.</p>

With a left-aligned image placed outside the <p</p>, later versions of Netscape Navigator 4 will stick all the paragraph text in an imaginary column to the right of the image, as if the Web designer had desired to create such a column. New paragraphs, in turn, will also appear in that unwanted column. Many a simple layout has been ruined in this way.

There is no solution to this problem. No matter which approach is used, some Netscape 4 users are going to get an ugly layout. Since an unwanted and mindlessly stupid column is preferable to text that is hidden behind an image, it is best to hope and pray that most Netscape 4.x users are equipped with a more recent version of the browser. Alternately, the Web designer can create pages that use no images whatsoever - always an attractive option. Finally, the designer can wrap images inside table cells, since that seems to solve most of these problems - at the terrible cost of adding needless, bandwidth-wasting and time-consuming code to every single Web page.

The good news is that Netscape Navigator 6, soon to be released, will be free of all such problems. And when it is released, at least 22 million AOL users will be migrated to the new browser by their provider.

Margins

As mentioned earlier, margins work well in all CSS-capable browsers, except that certain margin combinations can cause Netscape Navigator 4 to crash. More recent versions of Navigator 4 have fixed some, not all, of these crashing bugs.

Font-Style

Using CSS, it is easy to specify font styles such as italic.

.snappy {font-style: italic;}

H2 {font: 12px italic arial, helvetica, sans-serif;}

ADDRESS {font-style: italic;}

Unfortunately, many browsers style certain elements by default. For instance, in Explorer, ADDRESS is italic by default. Therefore, specifying italic in the Style Sheet causes the text to be doubly italicized. Leaving out "italic" causes the ADDRESS to be non-italicized in Navigator. The Web designer must decide which is a more disagreeable problem.

Possible font-styles are: normal (no style), italic, and oblique (same as italic, but not recognized in some browsers, with some fonts; have a nice day).

Font-Weight

Using CSS, it is easy to specify font weights such as bold. Sometimes, this is necessary. For instance, Netscape may not style <B>BOLD</B> text as bold unless the designer indicates the obvious in his or her Style Sheet.

.fatboy {font-style: bold;}

H2 {font: bold italic arial, helvetica, sans-serif;}

On the other hand, many versions of Explorer and Netscape will style certain elements bold by default. As a result, if the style sheet also indicates bold, the result may be twice-bolded typography.

H2 {font-style: bold;}

In Netscape, this headline will be twice-bolded. The look can be interesting on a platform, such as Mac OS, that handles typography well, and includes built-in text anti-aliasing. In Linux, the effect is ugly, and the text may be illegible, or at least tough to read. Have a nice day.

Summary and Further Reading

Pointing out these problems is not meant to discourage Web designers from harnessing the power of CSS, any more than a tour guide who warns you of potholes on the scenic road means to discourage you from exploring his city. Designers need to know what works and what doesn't in order to effectively use the good stuff.

The "Fear of Style Sheets" series at A List Apart discusses CSS problems and solutions in greater detail, and should be read by anyone who makes Web sites:

FEAR OF STYLE SHEETS

FEAR OF STYLE SHEETS 2

FEAR OF STYLE SHEETS 3