This question is specifically about selector scoring (specificity points), not the full cascade algorithm. Explain how selector weights are computed and compared, then mention tie-breakers briefly. Use it to debug why one rule wins, why another loses, and why !important often hides the real specificity problem. Keep the deep dive on origin/importance/order for the dedicated cascade question.
How do CSS selectors with higher specificity override others?
Overview
When multiple CSS rules apply to the same element, the browser resolves conflicts using specificity. Specificity is calculated based on the selector's type - IDs, classes, attributes, and element names each contribute differently to its weight. When a "simple" override refuses to apply, specificity is often the first debug clue.
Scope guard
This page answers “How are selectors scored?” If the interviewer asks about full conflict resolution order (origin, !important, layers, then source order), jump to <a href="/css/trivia/css-cascade-order">How does the CSS cascade determine which styles are applied?</a>.
Selector Type | Example | Specificity Weight |
|---|---|---|
Inline Styles | style='color: red;' | 1000 |
ID Selectors | header | 100 |
Class, Attribute, or Pseudo-class | .btn, [type='text'], :hover | 10 |
Element or Pseudo-element | div, p, ::before | 1 |
Universal or Inherited |
| 0 |
Example: Competing Rules
p { color: blue; } /* 1 */
.text { color: green; } /* 10 */
#intro { color: red; } /* 100 */
In this case, #intro (specificity 100) overrides .text (10) and p (1), resulting in red text.
Special Case: !important
The !important flag overrides all other specificity rules except inline styles with !important. Overusing it can lead to maintenance headaches, so use it sparingly and strategically.
Calculation Formula
Specificity is commonly represented as a four-part value (a,b,c,d):
- a – Inline styles (1 if present)
- b – Number of IDs
- c – Number of classes, attributes, pseudo-classes
- d – Number of element names and pseudo-elements
Example:
#nav .menu li:hover → (0,1,2,1) → Specificity = 121.Best Practices
- Keep selectors simple and avoid chaining too many elements or classes.
- Use class-based selectors for scalability instead of IDs.
- Reserve
!importantfor utility classes or third-party overrides. - Refactor conflicting styles rather than stacking specificity.
Think of specificity like a ranking system — inline styles are presidents, IDs are generals, classes are officers, and element selectors are soldiers. The higher rank always wins the battle for styling control.
- Specificity is the selector scoring step inside the cascade.
- Selector type weights decide which matching selector wins.
- If specificity ties, later source order wins (unless higher-priority cascade rules apply).
- Keep selectors simple and class-driven to avoid specificity wars.
Use the relevant interview-question hub first, then move into a concrete study plan before targeted company sets.