CSS Naming Conventions for IDs and Layout Blocks

When naming the IDs and classes in a document, keep in mind that the goal at all times is to separate content and structure from presentation. This means that for classes and IDs it is best to call out what the item is or does, as opposed to what it looks like. Note that in the example above, the content IDs were not named left-rail, middle-column, or right-rail, as that would have merely reflected their location on the page, rather than their function.

The W3C has an excellent note on its Web site discussing meaningful classes here (www.w3.org/QA/Tips/goodclassnames). This discussion also introduces the concept of semantics or meaning in markup.

Consider the following:

<style type=”text/css”>
p.rederror {color: red;}
p.bolduser { font-weight: bold; }
</style>
<p class=”rederror”>Warning: Username not found!</p>
<p class=”bolduser”><label for=”username”>Username:</label>
<input type=”text” id=”username” name=”username” /></p>

The width of an object in CSS

The width of an object is technically defined by the content area alone; however, these older versions of IE defined the width incorrectly, so any CSS object set with a width is actually measured incorrectly. This can wreak serious havoc on layouts, since the measurements for the dimensions of objects on pages are all wrong.

IE 6.0 in “standards” mode fixed this. However, it is now different from Internet Explorer 4 and 5, so Web authors have to deal with more than one measurement model while laying out pages using CSS.

What Microsoft did was define the width as including the content, padding, and borders. To help correct this problem, Microsoft introduced the DOCTYPE switch and “standards” and “quirks” modes that measure differently. However, their box model was different previously, so the “standards” and “quirks” differences are greater than many other Web browsers’ differences in these two modes. Other browsers have smaller nuances that happen in “quirks” mode, but they need to be watched for as well.

Web authors new to building Web standards-based layouts, but who may have built pages using Internet Explorer 5.x’s CSS box model, are in for a surprise when other browsers render the pages differently. Oftentimes, the belief is that other browsers were getting it wrong, or something broke in IE 6.0. The truth is, something was fixed, and the other guys had it right.

The CSS Boxes Were Measured All Wrong

When IE 4 came out in 1997, and when IE 5 for the Macintosh came out in 2000, Microsoft seemed to be doing fairly well with its Web browsers. Not that theywere great, but in terms of CSS support and user adoption, they were simply doing much better than Netscape 4 had fared. Netscape 6 was poorly received, and Microsoft had essentially won the so-called “Browser War.” With Internet Explorer 5 and 5.5 (the only games in town for many Web authors), it was assumed by most developers that the CSS support that they were getting used to was in fact correct. But just because something’s better or more popular doesn’t mean it’s correct.

Building a CSS-based layout using the building blocks contained in IE 4 and IE 5.x was misleading. A layout on a Web page is described with elements and tags representing a series of boxes and objects on a canvas—the document body. A CSS layout is defined by a box composed of an element that has a content area; padding around the top, right, bottom, and left; borders around the same areas; followed by margins around the object as well.

Oops, the Wrong Rendering Mode Broke the Page

For starters, there are extra background graphics behind the headers at the top of the page. Additionally, the layout seems to have shifted up the page slightly and the “Recommended” column is way off in the middle left compared to its usual symmetrical alignment. Scrolling down the page, things get even worse. The entire
information bar at the bottom of the page has lost its background color, except on hover, and the font sizes are off Adding back the DOCTYPE declaration is a simple thing in this case, but the lesson to be learned is that when widespread layout issues start happening, these problems are often symptomatic of a document-wide issue, such as the rendering mode, styles not being linked correctly, or missing tags in a sensitive location.

Quirks mode in particular can wreak havoc on a well-structured page. Using a validation tool to check the syntax of the page can be a huge help in cases like this.

There are specific documented issues, some of which will be discussed below, that exist for quirks and standards rendering modes. These often surface when code is being mixed with legacy markup, when browsers are reviewed, or when new designs are being produced. This is particularly an issue when looking at Internet Explorer 5.0 and 5.5 because although they do not feature multiple rendering modes, they are essentially always in “quirks” mode. This means designs will display differently than even in IE 6.0 as compared to 5.5 when working in a “standards” mode document because they are interpreted differently.