I have always used IDs for elements/CSS selectors where an element isn’t going to be used more than once, and class for elements that are to be repeated.
Recently I have been reading that this is bad practice and that I should always use classes in my CSS NOT IDs.
What is your opinion on this? What is the advantage of using class and why shouldn’t I be using IDs? Is it worth going over my current projects and changing all my CSS selectors to class names?
@alanshortis – There’s a couple of camps on this one. Some (like me) believe that using ID’s is perfectly fine if the site is small and the items truly unique.
Others believe that only classes should ever be used because of potential specificity issues – I.E – a DIV ID style surprisingly over-riding an additional class.
Personally I think you need to consider 2 things when making this decision – is the element truly unique and will you be working alone on this project? – If both of those are yes, then by all means use ID’s for styling, but if either is no then you need to be looking at classes to either keep your code light (if it’s a repeating style) and to avoid another developer losing their sanity if not working alone.
@andy_unleash Not to start a flame war, but there is nothing at all wrong with using a class even if an item is unique. Also, I’m of the school of thought that you should attempt to work in a smart manner, even when working alone. This means that the transition to working with a team is as seamless as possible.
I have done a ton of reading on this today… I cannot see a strong argument for NEVER using IDs. If I know that an element is to appear only once I don’t see why I shouldn’t just use the element ID.
I understand the argument that CSS should be reused across a site rather than specifying styles more than once. That’s fine, and in that case I use class names all the time.
A mixtire of IDs and classes works well for me so in the absesnce of a **good** reason to use only classes I’ll stick with what I know.
> I cannot see a strong argument for NEVER using IDs.
You’re right. Ultimately, sites will look just as good whichever you use and provided you bear in mind the potential problems, they can be avoided.
Besides the scalability, re-usability and specificity problems, I have another reason for not using ids.
I don’t think they are appropriate. Classes define characteristics of elements, while ids are for a single, specific element on a page. Background, padding, typography, etc are all characteristics and therefore (I think) be either inherent to the element (h1, p, ul, etc) or to the class. I have come from an OOP background, though (not web dev originally), so part of this bias is likely to stem from that.
Why do no-id advocates state specificity as a potential problem? Its a feature! I have never, ever encountered a project where ID specificity has been an issue. Have you? And I don’t mean where something didn’t work because of a single id in a previous selector…
And who says classes define characteristics and ids don’t? Why can’t an id have characteristics? So what if its a single specific element.
I also don’t understand why people care so much about conserving every single non-essential byte in a page and then proceed to load the entire page with classes.
Some say yes, some say no. I believe it’s more a matter of opinion than anything else (both camps have good points). This quote is a bit worrying, though:
> Recently I have been reading that this is bad practice
Please let’s not define the opinions of leading developers as good or bad practice.
I personally don’t get the hate for ID’s. I mean they are exactly that, identifiers for unique items. Classes in my mind are like a category, rather and a unique identifier.
An analogy for that would be say you have a blog, each post that has an ID of its title (unique to itself) but it’s category is that it’s a blog post.
So your ID might be #title-of-post and the class would be .blog-post.
As far as I can see there’s no reason not to use that, ID’s are available in HTML & CSS for a reason, to be used. Swapping that out for a class instead “just because” doesn’t make sense to me.
Either way, it’s personal preference.
> I have never, ever encountered a project where ID specificity has been an issue. Have you?
Only once, and it was during an update to a site I had finished some time before. I no longer use ids in my CSS though, so I’m not the best person to answer that.
> And who says classes define characteristics and ids don’t?
Just the way I see it. For me, ids name the element on the page. They are related to what the content is, not what it looks like. I would never attach an id to something in order to style it, so the only time I could use it in CSS is when a happy coincidence means that it is appropriate.
If ids define characteristics of elements (visual, not content), would you be happy adding one for purely styling purposes?
I will repeat what I said above, though. I don’t think using ids in CSS is wrong, or bad practice, or not effective. I just happen to choose not to myself, largely down to my own interpretation of what ids and classes “are”.
Here is my article on the subject. One of them, anyway: //css-tricks.com/a-line-in-the-sand/
Also worth noting that I haven’t anywhere else yet. The biggest problem with ID’s is the super high specificity that easily can bite you on big projects. But you can always knock ID’s specificity down to class level by only selecting them like:
My experience has been that ID’s always came back to become a problem later on. I had to come up with some kind of creative way around the ID’s.
As you get better at CSS you always go “why the hell did I do it that way?!” but ID’s specifically forced me to either rewrite the template or work around it. Either way it was a lot of extra work that I could have avoided had I just used classes instead.
You must be logged in to reply to this topic.