Almost never use IDs in CSS

[reubenmoes]

Using IDs in CSS almost always ends up with hair loss. I think we should have a note in here about using classes over IDs whenever we have control over it. Reasons:

1. Less hassle with overriding styles.
2. More reusability

@nathanshubert @eriku @verticalgrain @andmiriam @lancejanocha

[eriku]

I'm definitely on board with that. The fact that we now build "modular" websites means that we would only be able to have one module per page... meaning it's not all that modular anymore.

[nathansh]

Yeah, I think in general the documentation definitely does favour a classes over ID's approach, but I think we could be more specific in that. I definitely disagree that we should say 'almost never use IDs in CSS'. There definitely is such a trend, but I think it's a bit absolutist. I think the traditional "classes for reusable things, IDs for things that there's only one off" has some value. And you can give an element an ID and a class too. So things like the masthead of the site... I usually do header#masthead for that since there's only one masthead ever. So in HTML it'll have that ID, but I'll also give it a class for any reusable styles. But, if I do want to do something very specific for the masthead, I might have a #masthead { ... } in a partial with some very specific, one off css for it. I'm fairly sure this is appropriate use of IDs... all really one-off in nature and clearly such.

Having said that, I wouldn't be opposed to something along the lines of "In general favour classes over IDs. Only use IDs if you have a good, considered reason for doing so, in situations where that styling will never need to be reused. When using IDs, ensure that you aren't creating more specificity than needed for nested declaration blocks." Something like that.

[reubenmoes]

I would say in general, relying on styles nested under #header and #footer will often end up in specificity headaches. Here is a bit of a dumb example: say you wanted to theme all links based on what section (class added to body) you are in. Say you did something like assigning all the links in the header a color. Even though it is listed before the override styles, and the override style is on a more-root DOM element, the link would still be set by the ID class. I admit that this might actually be a valid use case (to keep the header links a certain color), so this might not be the best example, however I have run into issues like this in the past and it often ends up with !important all over the place or super specific CSS selectors to override things (matching all parent child items).

I would say in general, we should use a CSS Class over an ID, unless there is a strong reason to use an ID.

#header a {
  color: purple;
}
a {
  color: blue;
    .section-blog & {
      color: red;
    }
}

[nathansh]

I'd say if you do find yourself with a specificity problem, and most definitely if you use !important at all, then you're for sure not using the ID in a useful way. I think what's happening as a trend is instead of focusing on useful vs poor use of IDs people are saying don't use IDs at all, basically as a safety. It's probably a good idea to do that, but I'd just word it more like "favour classes" over "never use IDs because they're evil." Because, it's not really IDs that are the problem so much as how people tend to use them.

[reubenmoes]

Maybe if we just add a warning about using IDs and how there are specificity issues with it.

[nathansh]

I'd be into that.

[nathansh]

Maybe we should also a comment about how you should never need an !important and if you do that's the canary in the coal mine for deeper specificity problems.

[reubenmoes]

Maybe we just need a section about specificity where we can list all the specificity issues that you might come across.

[nathansh]

Sounds like a good approach

[eriku]

Should we also say a rough limit on nesting depth?

[nathansh]

I think I have a bit about not nesting unnecessarily deep.

[nathansh]

I don't think we can really assign a number to it though. I think there's room for common sense and evaluating it case by case with that one.

[eriku]

Basically something like ... If you're nesting 10+ levels then you might need to re-think your work :)

[nathansh]

Yeah, I think logical nesting would prevent you from ending up 10 levels deep. We could make that section more strongly worded though.