How Can We Minimize Markup When Building Sites with Web Standards?

---

Minimizing markup is an important topic to talk about. A huge benefit to creating sites with valid XHTML markup and CSS for presentation is the markup reduction. Less code means faster downloads—absolutely key for users on slow, 56K modem connections. Less code also means less server space and bandwidth consumption—this makes the bosses and system administrators smile.

The problem is that just simply making sure your pages conform to the W3C's specifications does not mean there will automatically be less code used. It's possible to pepper your valid markup with all sorts of unnecessary tags. Sure, it's valid, yet it could be littered with extraneous code in order to make the application of CSS a little easier.

Fear not, there are some tips to writing compact markup that will be valid, but will also provide just the right amount of style control on the CSS end. Let's take a look at a few simple things we can do to minimize our markup.

Descendant Selectors

Here we'll take a look at two methods for marking up a sidebar of a personal website that contains information, links, and other bits. We're stuffing all this good stuff inside of a <div> that we've given an id of "sidebar" in order to place it in a certain location of the browser window (more on CSS layouts in Part Two).

Method A: Class Happy

 <div >   <h3 >About This Site</h3>   <p>This is my site.</p>   <h3 >My Links</h3>   <ul >     <li ><a href="archives.html">Archives</a></li>     <li ><a href="about.html">About Me</a></li>   </ul> </div> 

I've seen markup similar to Method A on many sites. When designers first discover the power of CSS, it's easy to get carried away by assigning a class to any element that you'd like to style uniquely.

For the preceding example, we might have assigned the sideheading class to the two <h3> elements so that these headings will have a unique style from other headings on the page. We've also done the same for the <ul> and <li> elements.

Classified CSS

For style, let's say that we'd like the headings to be a serif font, orange, with a light gray bottom border. The sidelinks unordered list will have bullets turned off and the list items will be bold.

The CSS needed for the styling of Method A may look something like this:

 .sideheading {   font-family: Georgia, serif;   color: #c63;   border-bottom: 1px solid #ccc;   } .sidelinks {   list-style-type: none;   } .link {   font-weight: bold;   } 

By referencing each class that was specified in the markup, we can apply unique styles to those components. You could even imagine other portions of the page that are organized in this fashion—the navigation, footer, and content areas, each of them littered with dozens of classes in order to have full control over any element.

Sure, it works just fine—but there's an easy way to reduce the markup that's needed for all of those class labels, while at the same time making your CSS more readable and organized. Let's move on to Method B.

Method B: Natural Selection

 <div >   <h3>About This Site</h3>   <p>This is my site.</p>   <h3>My Links</h3>   <ul>     <li><a href="archives.html">Archives</a></li>     <li><a href="about.html">About Me</a></li>   </ul> </div> 

Nice and compact! But wait, were did all the classes go? Well, you'll find that we don't really need them—primarily due to the fact that we've contained all of these elements within a <div> that has a unique label, in this case sidebar.

Here's where the use of descendant selectors comes into play—by referencing elements that are contained within sidebar simply by their element names, we can eliminate all of those redundant class labels.

Contextual CSS

Let's look at the same styles that were applied to Method A, but this time we'll use descendant selectors to access the elements within our sidebar.

 #sidebar h3 {   font-family: Georgia, serif;   color: #c63;   border-bottom: 1px solid #ccc;   } #sidebar ul {   list-style-type: none;   } #sidebar li {   font-weight: bold;   } 

By using the #sidebar ID as the reference, we can give unique styles to any of the elements contained within. For instance, only <h3> elements that are within the sidebar <div> will receive those specific rules.

This contextual way of assigning styles to elements becomes key for reducing markup. Oftentimes, we need not pepper our elements with class names when we've set up a semantic structure around them.

Not Just for Sidebars

While we've only illustrated one section of a page, the sidebar, the same can be applied to an entire page structure—by slicing your markup into logical sections (perhaps #nav, #content, #sidebar, #footer), and then applying unique styles to those sections with descendant selection.

For instance, let's say that you've used <h3> heading tags in both the #content and #sidebar areas of your page and would like each rendered in a serif font. However, you'd like the text contained in the <h3> element to appear purple in one section and orange in the other.

There's no need to alter the markup by adding a class to either heading. We can set a global style that contains shared rules for all <h3> elements, and then use descendant selectors to color the heading depending on where it lives.

 h3 {   font-family: Georgia, serif; /* All h3s to be serif */   } #content h3 {   color: purple;   } #sidebar h3 {   color: orange;   } 

We've generically said that all <h3> elements should be in a serif font, while the color will be either purple or orange depending on its context. There is no need to repeat the shared rules (font-family in this case), which in turn minimizes the CSS and prevents repeating rules in multiple declarations.

Not only are we eliminating the need for extra markup in the form of class labels, but the CSS structure starts to make a lot more sense, making it more readable and easier to organize your declarations by page section. Going back to alter specific rules becomes all the easier—especially for large and complex layouts, where you may potentially have hundreds of CSS rules in one place.

For instance, in our example, if we had added the shared styles to each declaration and later wanted to change all <h3> elements to appear in sans serif, then we'd have to make that change three times instead of once.

Less Class Means Easier Maintenance

In addition to lessening the amount of code needed, using descendant selectors instead of assigning extraneous classes means future-friendly markup.

For instance, let's say that you would like the links in the sidebar to be red as opposed to the default blue that the rest of the page uses, so you went ahead and created a red class that was added to the anchor tags like this:

 <div >   <h3>About This Site</h3>   <p>This is my site.</p>   <h3>My Links</h3>   <ul>     <li><a href="archives.html" >Archives</a></li>     <li><a href="about.html" >About Me</a></li>   </ul> </div> 

And the CSS needed to turn those links red (provided that the default link color was something different) went something like the following:

 a:link.red {   color: red;   } 

This is all well and good and works perfectly fine. But, what if in the future you changed your mind and would like the same links to appear in green? Or more practically, your boss casually says, "Red is out this year. Make those sidebar links green." Sure, you could just make an alteration to the red class in the CSS and be done. But the markup is still saying red in the class attribute, which is of course semantically insignificant—as would be any color for the class name.

While this makes a good case for using nonpresentational names for classes, it would take less effort (and code) and stay more semantically sound if we were to not assign a class at all; rather, we could just use descendant selectors to tap into those sidebar links to style them any way we wished.

The markup would be identical to Method B, and the CSS needed to turn the sidebar links would be as follows:

 #sidebar li a:link {   color: red;   } 

In essence, we're saying, "Only anchors using the href attribute that are found in <li> tags within the sidebar <div> should be colored red."

Now, our markup stays lean and mean, and our CSS is the only tool needed for future updating—whether we'd like the links to appear red, green, bold, italic, etc.

Next, let's look at an additional way we can minimize our markup—eliminating unnecessary <div> tags in favor of a preexisting block-level element.

The Unnecessary <div>

In addition to reducing the number of class attributes needed for styling, there is another simple way we can reduce markup—by eliminating a <div> when a block-level element already exists as its child element. To demonstrate, let's look at two different methods.

Method A: <div> Happy

 <div >   <ul>     <li><a href="archives.html">Archives</a></li>     <li><a href="about.html">About</a></li>   </ul> </div> 

What we have here is an (extremely) small navigation menu that consists of nothing more than an unordered list. We've assigned the id of nav to the <div> that wraps around the whole list.

But why not assign the id directly to the <ul> element, which like the <div> is also block-level by nature? Let's look at Method B.

Method B: Lose the <div>

 <ul >   <li><a href="archives.html">Archives</a></li>   <li><a href="about.html">About</a></li> </ul> 

Method B shows us that we can toss out the extra <div> in favor of identifying the <ul> directly. Any styling for positioning, margins, padding, etc. can be applied to the <ul> just as easily as the <div>, so we in turn reduce our markup a bit by getting rid of the wrapper.

It's important to point out that this would only be appropriate if there are no other elements in addition to the <ul> contained within nav—for instance, a paragraph or <blockquote> or <form>. Since it's generally impractical for these elements to sit inside a <ul>, a <div> wrapper would make more sense. However, for instances such as I've outlined in Methods A and B, where the unordered list was the only element contained—then it makes sense to toss the <div> out. In fact, it's important to evaluate the existence of any containing element. Does it really need to be there? Is there already a block-level element that can be used? Compact markup awaits.

Other Examples

Another example of where a <div> could be eliminated is when wrapping a <form>. For instance, instead of this:

 <div >   <form>     ... form elements here ...   </form> </div> 

we could more easily do this:

 <form >   ... form elements here ... </form> 

Likewise, for a footer of a website that contained a single paragraph, instead of

 <div >   <p>Copyright 1999-2004 Dan Cederholm</p> </div> 

we could also do this:

 <p >Copyright 1999-2004 Dan Cederholm</p> 

provided of course that the footer contained no more than one paragraph.

---