Understanding the True Cost of ID Selectors
In CSS, the ID selector is the nuclear option of specificity. With a weight of one zero zero zero, it beats almost every other selector type. Many developers reach for it because it feels precise and powerful. But this power comes with severe long-term consequences.
The fundamental problem is uniqueness. An ID is meant to appear only once per page. When you use #header or #sidebar in your CSS, you’re saying this style applies to exactly one element. That sounds safe — until you need that same styling somewhere else.
The Reusability Trap
Imagine you’ve built a beautiful card component styled with #featured-card. It looks perfect on the homepage. Now marketing wants the same card in the sidebar. You can’t reuse the styles — the ID selector won’t match. So you either duplicate the CSS or change the HTML to use the same ID, breaking HTML validity.
This pattern repeats across entire codebases. Teams end up with dozens of nearly identical styles, each tied to a unique ID. Maintenance becomes exponentially harder with every new page or feature.
The Override Nightmare
Once an ID selector is in play, overriding it requires extreme measures. Classes lose. Multiple classes lose. Even descendant selectors with classes lose. The only reliable options are another ID, inline styles, or !important — all considered harmful in modern CSS architecture.
This creates a domino effect. One ID forces another developer to use !important. That forces the next to use even more specificity. Within months, the stylesheet becomes a battlefield of competing priorities.
The Better Alternative
Classes offer the same targeting power with dramatically lower specificity. A well-named utility or component class can be reused infinitely without cascade conflicts. Modern methodologies like BEM, SMACSS, and utility-first CSS all avoid IDs in styling for this exact reason.
When you remove IDs from your stylesheets, something magical happens: your CSS becomes predictable. Changes propagate naturally. Components become truly reusable. Teams stop fighting the cascade and start working with it.
The most powerful CSS is often the least specific.