Jump to main navigation, main content

Archived entry | Matt Wilcox .net

Naming and using id's and classes properly

Or, less presumptuously: How to name and apply classes and id’s for flexibility, future-proofing, and maintainability.

TL;DR: Always use semantic names. Never use presentational names. Even for classes.

Why are semantic class names important? For the same reason semantic IDs are. Just because one is intended for use only once on a page and the other can be re-used doesn’t change the validity of the argument on how to name well. They are both ways of labelling the content or purpose of the labeled element [note: purpose of the element, not the purpose of the class]. The benefit of naming semantically based on those properties is that the design remains abstracted, whilst still having a hook with which to work. No matter how you style it a .gallery will always be a .gallery. You know that it will contain a selection of images. You can hook into it and style it. And the name tells you a lot about the contents just from the name. Similarly imagine there are multiple designs/layouts for that mark-up (such as you might get with a Reponsive design). You can style a .gallery to fit however it needs to be displayed… but if you were using display focused class names such as “float”, or “red”, or “fancy-border” - then they may well be completely inappropriate or wrong in the other design/layout. Those names become an obstacle and not a help. Their un-abstracted mangling of the mark-up becomes obvious. The inflexibility becomes obvious. And what happens when you re-design? You revisit all of the mark-up painstakingly re-assigning, removing, and adding presentational class names? Ugh. No, CSS is meant to work on top of existing mark-up. It’s not meant to be entangled with it.

Well if CSS Lint and other such tools are saying we should use these presentational elements in order to reduce CSS bloat, how do I argue against that? With the argument above: that’s bad thinking that’s inflexible and confuses the purpose of mark-up and the purpose of CSS. Their “bloat” simply isn’t.

How do i measure bloat? As follows:

If the mark-up is not enhancing the semantics or accessibility of the document, that’s bloat. If it still needs another hook for the design, then name the hook based on the semantics and put it as far up the DOM tree as possible (to act as a hook for more objects) and avoid entangling the different roles of CSS and HTML. Bloat in mark-up is my least tolerated bloat because it is the least necessary and has the largest impact on future work and “higher level” technologies like CSS and JS.

CSS is bloated where selectors are overly complex (anything more than is required to achieve the required effect), where inheritance is not properly used (you only need specify things that are different, not re-specify things that are the same), and where the most concise option was not taken (e.g., using expanded border properties instead of short-hand). Bloat in CSS I tolerate more, because it is inherently less easy to write in a maintainable way for the human brain to quickly work on and also the best “efficient” manner from a file-size and speed perspective. People can work far faster on a file that makes sense to them than they can parsing machine-optimal code. Where the balance lies is subjective.

CSS is re-usable as is. You simply add a new selector to the rule-set. You do not, should not, whack a display class on the mark-up to “re-use” the CSS. Just like you don’t alter the mark-up simply to provide something for the JS to work on. You get the JS to do that itself. You get the CSS to do that itself. Exactly the same logic, for exactly the same reasons. Just because one’s designed for interaction and the other for display doesn’t change the simple philosophy that you leave the lower level technology as virginal as possible and keep the things that effect display in the files that control display, and the things that effect interaction in the files that control the interaction.

The arguments for optimising CSS for speed/performance are arguments I do not subscribe to. Well authored CSS works just fine without needing to resort to these kinds of CSS Lint tricks. And performance is largely a browser level issue which gets improved with every new release. Your polluted mark-up will not. It will stay mangled and messy for as long as you use it. Your page-render speeds will only ever get faster even if you leave it all alone.

Class names should never map directly to a CSS property, or a given visual effect you want to achieve (such as floating, or a border effect, or a background colour, etc.). It’s shockingly bad as an ideology because it encourages a direct mapping between class name and display action. A class name, like an ID, should be descriptive in a semantic sense. ie., it should describe something about the content of the tag to which it applies. “float” is not describing content. It is describing an action you want to perform. That is not abstraction. It is not useful.


skip to comment form
  1. Hernan Silva posted 207 days, 9hrs, 34mins after the entry and said:

    As far as I can understand css classes like ".alignleft, .alignright, .invisible, .hidden" and so on are wrong… but I'm not completely sure about some others I use very often:
    .inline-field, .last, .first, .lowercase and (specially these) .unstyled, .halfwidth and .hidden
    What do you think about them?

    Great article, thanks in advance.

  2. gibbitz posted 323 days, 4hrs, 5mins after the entry and said:

    someone doesn't have to work with enterprise level CMS's often. Providing classes that map directly to element style, font-color or background color is a convenient way of allowing the back-end to programmatically control the look of elements without having to directly edit semantic related CSS every time a page is added. Just my 2¢

From the archives

Other enteries filed under:

Web Development

Site information

Built with valid XHTML and CSS, designed with web standards and accessibility in mind. Best viewed in a modern browser [Firefox, Safari, Opera]

This domain and all content is a copy of my old website, for historical purposes only.