A front end convention for class use and JavaScript

Whenever I get asked to work on an existing website I haven't worked on before I tend to find a lot of CSS classes on elements that on first glance don't appear to do anything. As a naturally tidy person, this irks me. Why are they there? Is there some element much further down in the DOM that relies upon that class, or is there some bit of JavaScript somewhere that acts on it? Or is it simply an unused class that can be safely removed?

A quick search through the CSS and JS should answer this question pretty quickly, unless the class in question is a generic word, like 'select' or 'option'. Believe it or not, this happens more often than you'd think.

This isn't a huge problem, it's a small pain that adds a few extra minutes here and there. I'm just tired of it. I'd like to propose the following convention to remove this problem entirely.

  1. Where a class is used as a JavaScript reference no styles should be associated with that class, and the class should be prefixed with "js-".
  2. Styling should only be applied using classes without the "js-" prefix.
  3. IDs on HTML elements should only be used for JavaScript references. We should never apply styling using an ID.

In a bit more depth

I'm a big fan of clearly defined boundaries in front end, and also of doing it properly. For example, I don't think a class should be used for multiple purposes. If there's an element that uses a generic class but requires unique styling, add another class - don't add unique styles for that classname in that context.

The same goes for JavaScript. If you want to use a class name for JavaScript, don't use an existing one. In fact, that class should only be used for the JavaScript, so give it a prefix of "js-" to make it obvious that's what it's there for. Can you imagine how much clearer front end code would be if this convention was used? I can, because I use it.

Yes, it can result in an increase in the number of classes in your markup, but I think that's a microscopic price to pay for the long term clarity and flexibility this system offers.

The last bit

My third point is not only a key part of this convention, it's also how you should be writing CSS anyway. Don't style elements using an ID.

Why? For starters, you can only use that 'style' once on any page of your site. That may suit the site from the beginning, but trust me, your client is eventually going to come up with a creative reason why that part of the page you thought would only ever appear once now needs to be repeated multiple times.

The second reason is to do with the very nature of CSS - cascading. Using an ID for styling breaks the inheritance structure of CSS (IDs have precedence). Again, this may not seem like a problem from the beginning, but if you start using IDs for styling pretty soon you're going to end up writing some horribly convoluted CSS in order to override one of these styles (which might even require the use of *choke* !important). And if you don't understand that, I don't want to hire you.

Further thoughts

After I proposed this convention and it was generally agreed upon in our office, one of the developers pointed out that an equally valid way of approaching this would be to only use data attributes to hook in JavaScript code, thus separating out CSS from JavaScript completely. This is also a valid approach.

On reflection however, I prefer the "js-" prefix system, simply because it enforces a naming convention that can be more easily found when grepping through the code - but really, I'm just happy to have a convention.


This article is tagged with