Avoiding Specificity Wars

A specificity war occurs when developers add more specific selectors to override other styles, triggering an escalating cycle of increasing specificity — often ending in liberal use of !important.

The problem usually starts with one unnecessarily specific rule:

Avoid ID selectors and element-qualified class selectors in component CSS. Single-class selectors keep specificity flat and easy to override.

Long descendant chains increase specificity without adding clarity:

:where() has zero specificity, making utility classes that should never win override battles perfectly safe:

Declare CSS in layers. Layers are ordered by declaration priority, not specificity. A utility layer wins over a component layer regardless of their selector specificity:

!important should be a last resort reserved for:

• User accessibility stylesheets
• Overriding third-party inline styles
• Animation overrides (like animation-duration: 0.01ms !important for reduced motion)

CSS Modules, CSS-in-JS, and Sass @use namespacing provide automatic scoping by adding unique identifiers to class names. This eliminates global specificity conflicts entirely.

Add state via modifier classes rather than nesting into specific selectors. This keeps specificity flat:

Use CSS Specificity Graph or DevTools to visualize specificity across your stylesheet. A spiky, escalating graph indicates a specificity war. A flat, low graph indicates well-architected CSS.

Good naming conventions (BEM, utility classes) naturally prevent specificity wars by enforcing flat, single-class selectors. Adopting a naming methodology is the best long-term prevention.

Specificity wars start with unnecessarily specific selectors and escalate through override attempts. Prevention: use only single-class selectors, avoid IDs and descendent qualifiers in components, use :where() for utilities, and adopt @layer for explicit cascade priority. The naming convention is your first defense.