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 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.