8 simple rules for a robust, scalable CSS architecture

Jarno Rantanen has a great article outlining some CSS best practices. One in particular I’m happy to see there is the first on the list:

1. Always prefer classes

This is just to get the obvious out of the way.

Do not target ID’s (e.g. #header), because whenever you think there can be only one instance of something, on an infinite timescale, you’ll be proven wrong. One past example of this was when we wanted to weed out any data-binding bugs on a large application we were working on. We started two instances of our UI code, side-by-side in the same DOM, both bound to a shared instance of our data model. This was to make sure that all changes in the data model were correctly reflected in both UI’s. Any components that you might have assumed to always be unique, such as a header bar, no longer are. This is a great benchmark for surfacing other subtle bugs related to assumptions about uniqueness too, by the way. I digress, but the moral of the story is: there’s no situation where targeting an ID would be a better idea than targeting a class, so let’s just not, ever.

I’ve had half a dozen developers try to explain to me the advantage of IDs and… and the fact is there just doesn’t seem to be. There’s no difference between a class an and ID except a class is more expandable and (I’ll say it even though I hate the word) future proof.

It’s a useless semantic artifact.

You can check out all 8 rules here