Best Practices for ID and Class Names
Published on Aug 12, 2008 (updated Feb 5, 2024), filed under development (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 worked as a technical lead and engineering manager for small and large enterprises, 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.)