Jens Meiert

Best Practice for ID and Class Names

Jens O. Meiert, August 12, 2008 (↻ August 15, 2014).

This entry has been written by Jens the .

I’m working on another article for German Dr. Web mag, this time covering recommendations for IDs and classes, an issue likely as old as the Web itself. Taking a different approach than usual I’m feeling free to publish a “guerrilla sneak preview” in this place.

Talking about use of IDs and classes solely as style sheet selectors (as opposed to scripting hooks) and assuming knowledge about when to use what (I know that most of my readers are quite experienced), the best things to do are, in this order:

1. Keep Use of IDs and Classes to a Minimum

Unless IDs are needed for something other than styling (like serving as internal link targets), try to avoid them as well as classes as this is “cognitively easiest” and the least of a maintenance burden (don’t confuse structural—which can always happen and against which you cannot really protect yourself—with “visual” changes).

2. Use Functional ID and Class Names

Deriving names from functionality (for example nav, warning) is usually the second best option, as this is tied to the structure and helps conceptual understanding and collaboration. It is less of a maintenance problem as the page element in question might not change its meaning, and when it does, it requires more substantial changes, through changed contents.

3. Use Generic ID and Class Names

If you cannot derive a good name from an element’s function, or if you happen to introduce something solely for styling (e.g. for that still popular alternate styling of table rows), use generic, “neutral” names (for example alt, alternative). This is not necessarily ideal for understanding and collaboration but it is less likely to impose maintenance problems.

Also: Use Names That Are as Short as Possible But as Long as Necessary

Generally speaking, try to get to the point (nav), but don’t sacrifice comprehension (about).

❧ The truly worst thing to do, no matter what other people say (unfortunately I don’t find this, well, strange ALA article anymore), is to use presentational names (for example red, left, anything that has something to do with layout). This has to be avoided at all costs as it cuts you out of all maintenance advantages CSS gives you.

Skipped now but likely to be included in that upcoming article are “chameleon semantics” and “pseudo-namespaces.” While you might figure try a guess, look forward to that in a post on this site coming out later this month. :)

Comments (Closed)

  1. On August 12, 2008, 21:22 CEST, Seth said:

    Outstanding. I agree 100%, that is how IDs and classes should be handled. Straight to the point :)

  2. On August 12, 2008, 21:55 CEST, Robert said:

    So, you are definitely voting against the verbiage of classes as introduced by microformats like hAtom, hCard and the likes?

  3. On August 13, 2008, 12:53 CEST, Louis said:

    Your first point is totally going in the same direction as Camen Design website. Interesting evolution of the markup I must say.

  4. On August 13, 2008, 22:11 CEST, Jens O. Meiert said:

    Seth, cheers :)

    Robert, well, I already objected against microformats, but I wouldn’t go so far to raise doubts about every name they introduce. Many are okay, still they lack a “namespace.”

    Louis, yes :) And actually, some of my sites, including this one, once took the same approach. I’ll write more about that “soon” too :)

  5. On August 13, 2008, 23:08 CEST, Santhos Webdesign said:

    Totally agree with this. Allthough I sometimes use names like left or red in classnames. Don’t see why this is truly the worst thing to do…

  6. On August 19, 2008, 17:08 CEST, Niels Matthijs said:

    Hmmm, when looking at ids and classes solemnly as style sheet selectors, I kinda have to disagree with you on the first point.

    In your css file, do use ids and classes as much as possible, especially when the html element itself doesn’t fully semantically describes the component you are styling.

    Reason for this is that html might change, new tags might be introduced or new knowledge might be found (new discussions on semantics). The design has little to do with such decisions, so it shouldn’t be linked to it.

    Full article on this issue can be found here: leaving out css type selectors

  7. On August 20, 2008, 11:15 CEST, Jens O. Meiert said:

    Niels, who do you mean should “use ids and classes as much as possible”?

    Also, while I get the idea of what you’re trying to say, please keep in mind that classes can be used more than once and on different elements, so there might be good reasons for, say, th.alt and img.alt (generic class name indicating “alternative” instances of the elements to be styled). […]

  8. On August 20, 2008, 11:45 CEST, Divya said:

    This is a great idea. But I also think using ids should be kept to the minimum unless it is required.

  9. On August 20, 2008, 17:13 CEST, Niels Matthijs said:

    though I don’t quite understand “when the html element itself doesn’t fully semantically describes the component you are styling”)

    What I mean by that is that classes are often a more flexible and solid solution for styling, I’ll try my best to explain with an example.

    Take the case of marking up a telephone number. You probably have a div element with a class=”tel” or something. Inside the div is the actual number. Now if you want to add a textual caption (like “Tel:”) people often just include a span without any extra class as its not necessarily needed to style the caption.

    The css will look something like .tel span {}

    In this case though, a span doesn’t describe what the element represents, it’s a structural html element that merely says “this thingy is separated from the rest”. In this case, I’d advise to add a class=”caption” to the span so at least there’s a significant semantic gain (you now know what the span represents) and style it accordingly.

    The css now becomes .tel .caption {}

    The reason I do this is because now I can more easily change the html if needed (it could just as well be a div, or who knows what they wille come up with later). As the span (=container) doesn’t fully describe the component it represents (=caption) it’s better not to add your styles to it, as the html is not stable and could change.

    This is a theoretical stance of course, if you worry about filesizes and minimal html/css this is probably not very useful, but my priorities lie elsewhere (writing flexible html/css)

    Hope this explains a bit more what I tried to say :)

  10. On August 21, 2008, 15:39 CEST, SITER said:

    I often find myself using classes like ‘hidden’ or ‘padded’. In some sense it feels bad, but in the other, it doesn’t. In CSS, I define what padded means, and then assign it to elements like ‘article padded’. This is almost as bad as ‘red’, but because CSS doesn’t allow for proper inheritance, this will do for now. Please don’t crucify me for this, i know the good and the bad of this. It’s not the same as assigning style elements because for me ‘padded’ might mean ‘padding:5px’ or ‘padding: 5 10 5 20′ and i don’t want to fix every element to the new set of values. I could also have ‘branded’ or ‘attention’, so a div might end up with classes like ‘article padded branded attention’ - kind of like tagging, but with CSS classes.

  11. On August 22, 2008, 8:09 CEST, Jens O. Meiert said:

    Niels, thanks for clarifying. This approach reminds me of microformats (along with the tendency to get a little excessive) but with the additional constraint that there’s even less consensus on the meaning of the element in question (there’s “enforced,” solid agreement on HTML element semantics, some agreement on microformats semantics, but less to none on “individually assigned semantics”).

    Apart from that, this seems to go for cases in which HTML doesn’t offer you specific semantics. While this can be somehow addressed by using certain class names, it’s just fine to fall back to div and span for “neutral” structuring. There’s nobody going for your “caption,” in this case, anyway; “consensus,” again. (I hope this made sense.)

    ❧ This post is also available in German.

Read More

Have a look at the most popular posts, eventually including:

Found a mistake? Reward! Email me, jens@meiert.com.

You are here: meiert.comArchive for 2008 → Best Practice for ID and Class Names

Last update: August 15, 2014.