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.)