In a Class System, Can’t an ID Get a Fair Trial?

Jeremy Hilts, Web Developer

Sorry, this is not a Freudian debate on whether or not primal instincts have a place in modern society. That’s in the classroom down the hall…

In the world of XHTML and CSS, when should you use an ID and when should you use a class? I’ve heard this debate many times. In one particular instance, this decision is made for you: ASP.NET. If you’re using .NET, IDs are heavily used by the back end; if you need to style an element, it’s much easier to give it a class than it is to figure out what the ClientID will end up being.

Some believe that IDs should never be used when styling a website. Why would anyone disapprove of the use of IDs? The fact is: it’s just too specific. But wait! Isn’t it good to be specific?

One of the greatest attributes of CSS is inheritance. You can set a base style for an element, make a few modifications to the element based on its class (basically, what it represents), and then make further modifications to it based on where it lives in the document hierarchy.

If you were to use only classes to style your XHTML, you would be given a great amount of control over how the site looks and significantly reduce the time it takes to maintain the site. When making small tweaks to the look and feel of the site, you can define how significant you want that change to be by how specific your CSS descriptor is.

However, if you were to rely solely on IDs to style your XHTML, you would need to come up with a bunch of unique names – they can be used only once – and since a style applied to an ID trumps all other styles, a significant amount of planning would need to go into making the look and feel consistent.

Confused yet? Let me give an example.

XHTML:
<p>I am Paragraph A</p>
<p class=”significant”>I am Paragraph B</p>
<div class=”dark”>
    <p class=”significant”>I am paragraph C</p>
    <p id=”blue” class=”significant”>I am paragraph D</p>
</div>

CSS:
//All elements with an ID “blue” will have a bright aqua background and a blue border
#blue {
    background-color: Aqua;
    border: 1px solid Blue;
}
//All paragraphs will have a green border
p {
    border: 1px solid Green;
}
//All significant paragraphs will have a red background
p.significant {
    background-color: Red;
}
//All significant paragraphs within any division will have no border
div p.significant {
    border: none;
}
//All significant paragraphs within a dark division will have a dark red background
div.dark p.significant {
    background-color: DarkRed;
}

So what are the results? “Paragraph A” will have a green border. “Paragraph B” will have a green border and a red background. “Paragraph C” will have no border and a dark red background. “Paragraph D” will have a blue border and a bright aqua background. Wait… didn’t we say no borders for significant paragraphs within a division? Not to mention that bright aqua certainly does not belong within the “dark” division. Because IDs are so specific, whatever is mentioned within an ID’s CSS descriptor can never be overridden – you’re stuck with bright aqua and a blue border.

Now, I don’t want to knock IDs completely; they do have their uses. In a site that uses JavaScript, it’s much easier to find an element from its ID than it is to write a routine that searches the document for a class name. In most cases, it’s more appropriate to use IDs when using JavaScript, as you wouldn’t want the JavaScript to affect elements that it was never meant to affect. I suppose it’s a good thing that you can define both.

To recap: IDs are typically thought of as bad practice in the world of CSS. They’re way too specific and cause you to lose some of the finer points of CSS – namely, cascading. Oh, and that’s what the “C” means. That’s a whole 1/3 of the abbreviation! IDs do have their uses; however, they’re best left out of the styling business.

Also, inline styles are bad.