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?
The main selling point in terms of only using classes as styling hooks is that you are always working with a consistent specificity. It's also pretty easy to only have to worry about classes!
The only reason I can think of to use id over class is when you want to use :target, with the uses being shown by Chris here. To be honest, though, I've only ever used :target once.
@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 to agree with @joshuanhibbert. I was using ID's on my site as well for specific areas. I found it much easier and cleaner to maintain after switching.
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.
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".
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.
Personally I start to use more classes than ID for now. I feel that specifies the name of the class is much easier than ID, particularly for similarity modeling without having to repeat the declaration multiple time in another selectors:
I just use the ID to indicate that the location is a primary location, "This is the primary location, primary section, primary block that is strong, and assertive". Although I didn't think to use it in the CSS selector.
Try not to worry with the old CSS in my personal blog which is still widely used ID, but began to use more classes to the customer site/blog.
I've coded everything under the sun and I've never run into a problem using ids. If anything maybe it's helped me become a specificity pro. I use them as I initially learned them. Use ids for page layout (header, sidebar, footer, etc) and classes for anything that may be used more than once. I believe using the #header and etc give you hooks that you can grab when ever you need to be more specific. In fact this is the most I've ever thought on the subject because I've never had to.
However, that said, I can see the allure to only use classes as well. One less thing to consider while coding. Just only use .class. You can add multiple classes to the same tag. All things good. But I'll prob stick with what I'm used to. Ids and classes. That's crazy though css lint actually giving a warning over use if ids. Who are they to warn me that I say tomAto and they say tomOto?
@wolfcry911 Yes, you are right, specificity is a feature. The issue is that many people don't fully understand it, and get caught out by it. Also, if you are properly minifying and gzipping then excess classes don't really matter.
In the end though, it's just personal preference. You are not 'right' or 'wrong' no matter which technique you prefer.
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?
The main selling point in terms of only using classes as styling hooks is that you are always working with a consistent specificity. It's also pretty easy to only have to worry about classes!
The only reason I can think of to use id over class is when you want to use :target, with the uses being shown by Chris here. To be honest, though, I've only ever used :target once.
@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 to agree with @joshuanhibbert. I was using ID's on my site as well for specific areas. I found it much easier and cleaner to maintain after switching.
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.
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:
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.
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.
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: http://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.
@chriscoyier Have you seen the GitHub video on CSS selector performance? I wouldn't advice using attribute selectors on large scale projects.
Personally I start to use more classes than ID for now. I feel that specifies the name of the class is much easier than ID, particularly for similarity modeling without having to repeat the declaration multiple time in another selectors:
I just use the ID to indicate that the location is a primary location, "This is the primary location, primary section, primary block that is strong, and assertive". Although I didn't think to use it in the CSS selector.
Try not to worry with the old CSS in my personal blog which is still widely used ID, but began to use more classes to the customer site/blog.
Personally...
I've coded everything under the sun and I've never run into a problem using ids. If anything maybe it's helped me become a specificity pro. I use them as I initially learned them. Use ids for page layout (header, sidebar, footer, etc) and classes for anything that may be used more than once. I believe using the #header and etc give you hooks that you can grab when ever you need to be more specific. In fact this is the most I've ever thought on the subject because I've never had to.
However, that said, I can see the allure to only use classes as well. One less thing to consider while coding. Just only use .class. You can add multiple classes to the same tag. All things good. But I'll prob stick with what I'm used to. Ids and classes. That's crazy though css lint actually giving a warning over use if ids. Who are they to warn me that I say tomAto and they say tomOto?
@wolfcry911 Yes, you are right, specificity is a feature. The issue is that many people don't fully understand it, and get caught out by it. Also, if you are properly minifying and gzipping then excess classes don't really matter.
In the end though, it's just personal preference. You are not 'right' or 'wrong' no matter which technique you prefer.