Debugging scenarioMedium~10 minBrowser Rendering, CSS & Storage / 3 of 5

Interview question

A CSS rule appears correct but does not win, or unexpectedly affects descendants. How would you debug the cascade?

Debugs matched rules, cascade origin, importance, layers, specificity, source order, inheritance, and computed values.

1Say itAnswer out loud first

2CompareCompare with Core answer

3RefineRefine with Stronger and Advanced

TL;DR

I inspect the element's matched and computed styles in DevTools. First I confirm the selector matches and the stylesheet loaded. Then I check cascade origin, importance, cascade layers, specificity, and source order. If the property is inherited, I trace the computed value from the ancestor and distinguish inheritance from a selector that directly matched the child.

Full answer below

Practice focus

A systematic CSS investigation that avoids escalating specificity blindly.

Answer first

Answer path

Core answer first, then checkpoints toward a stronger answer.

Start
Core answer
Start here. This is the direct spoken answer to practice first.
Overview
The first task is to determine whether the selector matched. Only then does it make sense to ask why another declaration won.
I inspect the element's matched and computed styles in DevTools. First I confirm the selector matches and the stylesheet loaded. Then I check cascade origin, importance, cascade layers, specificity, and source order. If the property is inherited, I trace the computed value from the ancestor and distinguish inheritance from a selector that directly matched the child.
Checkpoint
Stronger answer
Optional upgrade with examples, trade-offs, and sharper phrasing.
I compare the exact winning declaration instead of adding a more specific selector. A component can lose because a rule is in a lower-priority layer even when its specificity looks higher, or because a shorthand reset another longhand. Custom properties also inherit their token value, while the property using that token is resolved where it is applied. I reduce the case before changing the architecture.
Finish
Advanced answer
Optional deeper angle for production judgment and nuance.
The durable fix is usually predictable style ownership: deliberate layers, low-specificity component selectors, explicit tokens, and limited escape hatches. I avoid routine !important because it transfers the conflict to a harder level, though it can be justified in a controlled utility or user override layer. Visual regression tests cover critical states, but they complement rather than replace an understandable cascade. For third-party styles, I isolate the integration or place its overrides in a named layer instead of escalating selectors across the application.

Review signals

Use these to catch weak phrasing, shallow reasoning, and risky claims.

Common mistakesCandidateCommon mistakesMistakes that weaken the answer or signal shallow understanding.Open details

Details

Increasing specificity before checking whether the rule matched.
Treating inherited values as direct selector matches.
Ignoring cascade layers and shorthand resets.
Using !important as the default fix.

Red flagsCandidateRed flagsSignals that an interviewer may treat as risky.Open details

Details

Selectors grow continuously to beat previous selectors.
Global rules leak into components with no ownership boundary.
The fix depends on fragile stylesheet load order.

Follow-up prompts

Quick interviewer prompts inside this drill.

Follow-up questionsCandidateFollow-up questionsLikely next questions after the main answer.Open details

Details

Treat these as the next interviewer turn. Answer one out loud, then save the gap in your practice notes.

What decides the winner before specificity?
How can a shorthand reset another property?
How do custom properties participate in inheritance?

Continue the section

Next in Browser Rendering, CSS & Storage: Choose browser storage

Step 4 of 5

How would you choose among cookies, localStorage, sessionStorage, and IndexedDB for browser data?

Practice route

Read core answer Review checklist Follow-up prompts Track progress

Finished this drill?

Practice freely. Sign in only when you want to save completion, confidence, notes, or bookmarks.

New to Aporeon? Create account

Drill details

Human editorial direction

Aporeon is shaped by Aleksandar Tomovski, a software developer with experience on both sides of technical interviews. Content is reviewed for accuracy, natural spoken delivery, useful depth, and honest trade-offs.

About the creator Editorial standards

Was this drill useful?