"No, the primary reason is that IDs prevent reuse."
The fact that they cannot be reused in a single page is what makes IDs so useful.
There are benefits of IDs others mentioned, but for me properly used IDs make CSS so much clearer. An ID in CSS code is a flag saying: "custom-crafted for this part of the page only, not to be reused", or "non-modular code".
Unlike a class, an ID informs me with 100% certainty that if modified, it will not affect other instances on the page, because there are none. It's hard to overestimate the value of such information, especially when working on older or someone else's code.
>The fact that [IDs] cannot be reused in a single page is what makes IDs so useful.
This isn't enforced by browsers. They will happily render all elements with the same ID and apply the same styles to all of them.
This kind of thing really isn't useful. If you accidentally put the logo twice on the page, it will be clearly visible. It virtually never happens and when it does it isn't hard to track down.
This "just once" property of IDs really doesn't add anything useful.
>Unlike a class, an ID informs me with 100% certainty that if modified, it will not affect other instances on the page, because there are none.
If I modify one of my building blocks, I know that every instance of it will now look like this.
>This isn't enforced by browsers. They will happily render all elements with the same ID and apply the same styles to all of them.
We live in post-xhtml times, browsers will try to make sense and render all sorts of bad code.
>If you accidentally put the logo twice on the page, it will be clearly visible. It virtually never happens and when it does it isn't hard to track down.
You're assuming the visual difference in applied style is always clearly visible, like a repeated logo. No, it's often not, not until someone changes something in a class and the change is populated everywhere the class was reused. An ID is a guarantee it was not reused, or at the very least serves as a "do not reuse" sign.
Why not? If someone wants to reuse something, they probably have a good reason. Why would you get in their way? You won't gain anything from doing that.
> If I modify one of my building blocks, I know that every instance of it will now look like this.
But that's based on your own system, which may be non-obvious to other developers. The rules of valid HTML dictate the situation in which you will encounter a given ID, so this communicates something to every developer who sees IDs used in a given selector. To me that's tremendously valuable, and far more useful than trying to graft additional meanings onto parts of a single classname.
Whether that system is BEM, OOCSS, SMACSS or some other syntax, this kind of naming convention isn't a native part of CSS.
> But that's based on your own system, which may be non-obvious to other developers.
Yes, conventions are like that. You have to read the docs.
> [...] this kind of naming convention isn't a native part of CSS.
That's true for naming conventions in general.
Well, this stuff was added for a reason. If you know the rules, the SCSS and markup becomes way easier to navigate. Additionally, there are now many properties which can be automatically verified.
It adds structure which wouldn't be there otherwise.
The fact that they cannot be reused in a single page is what makes IDs so useful.
There are benefits of IDs others mentioned, but for me properly used IDs make CSS so much clearer. An ID in CSS code is a flag saying: "custom-crafted for this part of the page only, not to be reused", or "non-modular code".
Unlike a class, an ID informs me with 100% certainty that if modified, it will not affect other instances on the page, because there are none. It's hard to overestimate the value of such information, especially when working on older or someone else's code.