Best Practices for ID and Class Names

Published on Aug 12, 2008 (updated Feb 5, 2024), filed under development, css (feed). (Share this on Mastodon or Bluesky?)

This and many other posts are also available as a pretty, well-behaved ebook: On Web Development. If the optimization of CSS is of particular import to you, I’ve collected several concepts in a brief book: CSS Optimization Basics.

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 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 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, there’s need for more substantial changes.

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 aux or alt, alternative). This isn’t 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, is to use presentational names (for example red, left, anything that’s related to how an element looks or behaves). This has to be avoided at all cost as it cuts you out of the maintenance advantages CSS gives you.

Skipped here but likely to be included in that upcoming article are “chameleon semantics” and “pseudo-namespaces.” But maybe that’s already telling 😊

Update (August 19, 2021)

In his excellent A Philosophy of Software Design, John Ousterhout writes about the “vague name” red flag: “If a variable or method name is broad enough to refer to many different things, then it doesn’t convey much information to the developer and the underlying entity is more likely to be misused.”

You can apply this to generic ID and class names, too, which suggests to use generic names carefully. They’re more viable in small projects rather than large ones.

About Me

I’m Jens (long: Jens Oliver Meiert), and I’m a web developer, manager, and author. I’ve been working as a technical lead and engineering manager for companies you’ve never heard of and companies you use every day, I’m an occasional contributor to web standards (like HTML, CSS, WCAG), and I write and review books for O’Reilly and Frontend Dogma.

I love trying things, not only in web development and engineering management, but also in other areas like philosophy. Here on meiert.com I share some of my experiences and views. (I value you being critical, interpreting charitably, and giving feedback.)