I recently worked on a project with a relatively new to CSS developer, and I forgot how much people rely on IDs. I almost gave that person a blanket statement to not use IDs, but I guided him towards reusable classes instead.
It all boils down to reusability though. If you have an ID, say for a #promoCol, sure, there may only be 1 promo column on the page now, but what happens when the client/designer says, hey we need a promoCol on the right side as well? Do you go back and refactor #promoCol to .promoCol (as it should have been originally, IMO), or just add #promoCol2?
Maybe a column is a bad example as you might be able to deduce ahead of time that there MIGHT be more than 1. But you could say that of just about any element on the page. Theater was mentioned, but I've worked on sites where we had to add a second theater second to a page (yah...I know, wasn't my call.)
I would even go so far as to say, if you use IDs in any significant factor in your CSS, you are doing it wrong. And it has absolutely nothing to do with knowing how to work specificity, and everything to do with the additional flexibility not using IDs provides you (or your co-workers) both during an initial build and down the line when maintaining or updating a project.
Do you go back and refactor #promoCol to .promoCol?
Yeah, that's exactly what you do. Just because your new dev doesn't know how to refactor (and it's hardly even refactoring, it's like a two-line diff) doesn't mean we all shouldn't use IDs.
IDs have an extra bit of self-documentation when you use them - when I see #promoCol, I know instantly that there's just one promocol, and I don't have to worry about breaking the look of another promocol while I'm fiddling with the CSS in there. If there's a class, you don't know how many things it applies to until you've done a grep over your project.
I would much rather prefer for there to be #promoCol and #promoCol2. From my experience, promoCol2 often ends having more things in different than common from promoCol1.
I love IDs because I don't need to think about changing a class to fix one page only to see the same class screw up another page.
It is really easy to shoot yourself in the foot when you add ids to the mix, and there's nothing CSS-wise you can do with ids that you can't do with classes.
It all boils down to reusability though. If you have an ID, say for a #promoCol, sure, there may only be 1 promo column on the page now, but what happens when the client/designer says, hey we need a promoCol on the right side as well? Do you go back and refactor #promoCol to .promoCol (as it should have been originally, IMO), or just add #promoCol2?
Maybe a column is a bad example as you might be able to deduce ahead of time that there MIGHT be more than 1. But you could say that of just about any element on the page. Theater was mentioned, but I've worked on sites where we had to add a second theater second to a page (yah...I know, wasn't my call.)
I would even go so far as to say, if you use IDs in any significant factor in your CSS, you are doing it wrong. And it has absolutely nothing to do with knowing how to work specificity, and everything to do with the additional flexibility not using IDs provides you (or your co-workers) both during an initial build and down the line when maintaining or updating a project.