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.

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.

CSS Web Site Planning Today

The vast majority of the effort and project planning on large-scale Web projects today trivializes the UI layer and treats it as an afterthought, when in fact it can deeply impact content management, Web applications, search engine optimization (SEO), bandwidth costs, site performance, and maintenance efforts. Plans typically start with the back-end software and only touch on the UI in terms of design.

Fortunately, there are ways to pare down the long-term risks and remove the constraints of traditional Web coding. Embracing modern techniques starts with the W3C and its recommendations, often called Web standards.

The issue should be considered not only in terms of your design, but also where the content management, applications, and other dynamic systems are concerned. If a Web site is to reap the benefits of a Web standards-based UI, it needs to be considered at all levels, and plans should be introduced that will allow the site to grow intelligently.