Debug a rule that refuses to win the way interviewers probe it: cascade order (importance, origin, layers, specificity, source order), how selector specificity is scored, why an id beats any number of classes, and when !important hides the real problem instead of fixing it.
Frontend interview practice question
Why doesn't my CSS override apply? Cascade, specificity, and !important
Interview quick answer
Interview focus
This CSS interview question tests whether you can explain Your CSS Override Doesn't Apply: Specificity, connect it to production trade-offs, and handle common follow-up questions.
- Your CSS Override Doesn't Apply: Specificity explanation without falling back to memorized definitions
- Cascade and Specificity reasoning, edge cases, and production failure modes
- How you would answer the most likely CSS interview follow-up
Interview answer drill
Use this CSS interview question to rehearse a quick answer, common mistake, follow-up, and production pitfall.
Full interview answer
The bug to explain
Your rule is later in the file, it matches the element, and DevTools shows it crossed out. The cascade did not pick it. Browsers resolve conflicting declarations in a fixed order: importance, origin, cascade layers, specificity, then source order. Source order only matters when everything else ties, and a single #id or an inline style outranks any number of classes. The sections below cover the order, selector scoring, and the id vs class decision that produces most override bugs.
Overview
The cascade is the algorithm browsers use to combine styles from different sources. When multiple rules target the same element, CSS evaluates them using a four-step hierarchy: importance, origin, specificity, and order of appearance.
Step | Concept | Explanation |
|---|---|---|
1 | Importance | Rules marked with |
2 | Origin | Inline styles > author stylesheets > user stylesheets > browser defaults. |
3 | Specificity | More specific selectors take precedence (e.g., IDs > classes > elements). |
4 | Source Order | When all else is equal, the rule defined last in the CSS wins. |
CSS
p { color: blue; } /* element selector */
.text { color: green; } /* class selector */
#intro { color: red; } /* ID selector */
p { color: purple !important; } /* overrides all */
Result: The !important rule wins even though the ID selector is more specific. Without !important, the ID selector would take priority.
Best Practices
- Keep selectors consistent and avoid unnecessary complexity.
- Minimize use of
!important; rely on proper structure and specificity instead. - Understand how frameworks (e.g., Bootstrap) use cascade layers and resets.
- Use the browser’s ‘Computed Styles’ panel to debug cascading conflicts.
Specificity: how selectors are scored
Specificity is calculated from the selector’s parts. 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.
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 |
CSS
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.
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.id vs class selectors
Both target elements, but they carry different weight and intent. An id is unique per page and scores 100; a class is reusable and scores 10, which is why class-based styling scales better in component systems: overrides stay cheap. Reserve ids for anchors and JavaScript hooks.
Aspect | id Selector | class Selector |
|---|---|---|
Syntax | elementID | .elementClass |
Uniqueness | Must be unique per page | Can be used on multiple elements |
Specificity | Higher (overrides class styles) | Lower (can be overridden by id) |
Use Case | For specific, unique components | For reusable, shared styles |
Example HTML | <div id='header'> | <div class='card'> |
Best practices
- Keep selectors simple and class-driven to avoid specificity wars.
- Use
@layerto order framework and app styles instead of stacking specificity. - Reserve
!importantfor utility classes or third-party overrides. - Refactor conflicting styles rather than adding more selectors.
The cascade is like a courtroom: importance is the judge, specificity is the lawyer’s strength, and source order is who speaks last.
Practical scenario
A component library sets button styles, and your app needs overrides. The cascade order determines whether your app styles actually win.
Common pitfalls
- Assuming later rules always win without checking specificity.
- Overusing
!importantand making future overrides impossible. - Forgetting inline styles beat most stylesheet rules.
Lower specificity is easier to maintain but may lose to library styles. Use DevTools to inspect the winning rule in the computed panel.
Guides
Preparing for interviews?
Use this as one explanation rep, then continue with the CSS interview questions cluster or a guided prep path.
Open frontend interview questionsPractice more CSS interview questionsOpen Essential 60Open Machine Coding HubOpen Question LibraryOpen system design questionsOpen interview preparation guideOpen system design blueprintOpen framework prep pathsOpen Study PlansOpen 7-day crash study planBrowse company questions
Built in public
The code behind FrontendAtlas lives on GitHub. A star helps other frontend engineers find it.