Sometimes when I’m reviewing code, I advise a colleague not to use IDs for CSS style selectors, and inevitably get asked why. Like standing in queues, making a cup of tea or applying a full face of makeup in the dark at 6am, avoiding IDs in CSS is something I do without thinking. I've been doing it for so long without questioning it, that it takes me a minute before I can explain to other people why. So with that in mind, here’s a list of reasons why I avoid using IDs in my stylesheets, and prefer classes instead.
1. Class specificity is lower than ID specificity
IDs have a much higher specificity than classes. A class on its own can't overwrite styles belonging to an ID. To "beat" the ID, you would need either more IDs or to use !important, which can begin specificity wars in your stylesheets. You may even need to restructure your HTML. Ideally, styles should be easy to override and extend, to make your CSS maintainable and pleasant to work with.
2. Classes can be reused
IDs should be unique on a page. This means that if you attach a style to an ID, you won't be able to reuse it within the same webpage. Classes, however, can appear on several HTML elements on the same page. Being able to reuse styles is one of the advantages of CSS. For example, it would be difficult to style a list element <li> directly using just IDs. Admittedly, not every style needs to be reused, but it's nice to have the option.
3. A consistent convention
It's simpler for developers working in a codebase to know that CSS is attached to classes, and that IDs are used for other purposes. Using only the class attribute to define styles is easier for others to understand instead of a combination of the class and id attributes.
4. An element can have several classes, but only one ID
You can add many classes to a HTML element, for example <div class="text-bold banner-text js-banner-text"></div>. Here, there are classes for styling, and a class for a JavaScript hook, all grouped together in the class attribute. It's possible to name IDs using these conventions too, but remember that it's not valid to have more than one ID per element. This means that you can't overload ID names like the class example above, e.g. <div id="text-bold banner-text js-banner-text"></div>.
Using a combination of classes to style an element is a common pattern. Additionally, it's a good idea to use a naming convention for selectors used only by JavaScript or automated tests. For example, if I see a class prefixed with js-, I know that it's used in JavaScript somewhere and isn't responsible for styles and should proceed with caution before editing it. (Commonly the qa- prefix is also used as a hook for testing.) I personally like to keep all my hooks and styling classes together in one attribute instead of sharing them between classes and IDs.
Disclaimer
Of course, this advice comes with the usual disclaimer attached. You understand your code and the context of your problem more than any random blog post, and if you think it makes sense to write CSS with IDs, then go ahead and use an ID. IDs are completely valid to use in CSS stylesheets.
Note
This is not to say that you shouldn't use IDs in your HTML. IDs have many uses in a webpage aside from being a CSS selector. For example as page anchors, fragment identifiers or to link labels to form fields.
P.S.
While researching this post, I found this StackOverflow answer which recommends using IDs for defining styles - a good reminder that popular opinions in frontend web development can change!
Top comments (22)
We like to keep
classes for style,ids for #links, andrelfor the occasional JS selector. To each their own, and at some super high level there may be reasons to hyper-optimize - but for teaching especially, this really helps keep things extremely clear and readable.Another unrelated reason to avoid using IDs: they are automatically created as properties on the global window object in JS.
I think this should be the first reason not to use ids
Great post!
In the course I'm doing for full-stack development, in the CSS section it was advised to never use IDs ever, unless you absolutely need to. IDs are better used for JS it was suggested, and if anything it's lazy and inefficent code.
I wish I had known that when I learnt CSS a while ago and in my current codebase it's littered with IDs aha.
That's great that you can look critically at your old code and know how you'd improve it - you're definitely improving as a dev!
We should all start styling using type selectors and not class. We should start from the lower layer (type) and then go for attributes and class selection, and if we need it, ending with ID's.
Why using a .p {} class when we can use the lower selecto p {} and let users extend/override our style with attributes or classes?
I feel it the same.
A little example:
Specificity is good. Embrace it, don't fight it. If you want to style an element a particular way because it is that element and no other, using its id in your selector is the right solution. You won't ever want to override it with a class.
What is the your recommendation for use of id's? I'm currently using them for single page elements that are not going to be reused i.e. a front page carousel or a contact form that won't be reused. Is there any reason you can't just use classes all the time?
No there's no reason you can't use classes everywhere for styling. Even if you think you'll only want to use a style once, there's no reason not to use a class for it. I can see why you would define "single-use" styles on the IDs but there isn't any advantage to doing that except for the higher specificity. I prefer to reserve IDs for other uses such as form labels and linking to anchor tags and keep all my styles defined by classes, for consistency.
using ids is way more performant for css rendering not that it will make much difference when compared to other optimiztions but if you using web components where ids don't leak out of the shadow dom it doesn't make much since to use class for single use since that class can't be used anywhere else.
This post is exactly the reason why I avoid using IDs in my CSS, classes makes you style different HTML element and still looks neat...in a way I don't really like having !important in my stylesheet....another reason i avoid IDs
I just like to remind all who read this that this pice is someone's opinion and is disputed as to whether or not "avoiding" IDs in your HTML/styling should ultimately be avoided as some sort of "best practice".
There is absolutely nothing wrong with using an ID for a CSS selector when done appropriately.
And actually all the reasons given in the article are all reasons FOR using them.
I do also heavily support the use of
classesas much as possible and I personally use an ID so high in the DOM as to be able to override highly specific, often chained class selectors, simply with an ID.The fact that an ID gets automatically created as properties on the DOM is yet another reason to use them, when applicable.
I'm all for not using IDs as selectors if thats your personal preference, let's just not discourage using them at all as a general best practice because, well, it's not some best practice not to use them.
I'd also recommend not discouraging others to not use a tool just because you have not yet explored all uses for them. How about an unbiased article about how and when they ARE useful?
For instance, I'd prefer there be an ID on each header of this page, should I link it and want a user to jump directly to that portion of the page, like it was designed to do.
Just my two cents.
Think of Darwin classification tree. Nodes are classes, leafs are ids. I have an ID and a Class. I have common properties of a human, but I have my own properties that nobody else has. So HTML names (and CSS selector shortcuts # and .) for these attributes makes perfect sense. Use class for Class and id for unique and only.***
***The only real issue is a legacy bug in JS that creates a global window variables that hold references to the elements with id attributes. But with most modern frameworks that is not a problem, since most of the time you work with VDOM, not DOM.