Goal
You’ll build a real, repeatable debugging process for “why doesn’t my CSS look right” using actual browser developer tools, instead of randomly changing values and hoping something eventually works.
Learn
Browser developer tools (right-click on any element → Inspect) show you, for that specific element: exactly which CSS rules are being applied to it from every source, which specific rules are being overridden (usually shown visually with a strikethrough through the property), and the actual computed box model values as real numbers, not just what you wrote in the CSS. This turns debugging from guessing into directly observing what the browser is actually doing.
A reliable debugging order, useful across almost any CSS problem:
- Confirm the element you’re inspecting is actually the one you think it is. This sounds obvious, but clicking slightly off-target (inspecting a wrapping container instead of the element inside it, for example) is a common, easy-to-miss mistake that wastes real debugging time.
- Check for overridden/struck-through rules. This tells you something else is winning the specificity battle, directly pointing you toward the cascade rules from Part 1.
- Check the computed box model diagram for unexpected padding, margin, or width values that don’t match what you assumed, directly connecting to Part 1’s box model lesson.
Decision Task
A button’s background color isn’t changing despite your new CSS rule. You open dev tools and see your rule listed, but with a strikethrough through it. Before reading on: what does that specifically tell you, and what’s the next concrete thing to check?
Reveal the Answer
A struck-through rule means it exists and was genuinely read by the browser, but something else with equal or higher specificity is winning instead, based on the exact cascade rules from Part 1. The next concrete step is checking which other rule is actually applying, usually visible right above or below the struck-through one in the same dev tools panel, and comparing their specificity directly, applying the cascade lesson as real debugging rather than just a written exercise.
Common Mistake
Assuming a style “isn’t working” means CSS itself is somehow broken or unpredictable, and reaching for !important immediately rather than spending even 30 seconds actually inspecting why in dev tools. Almost every “CSS isn’t working” situation has a specific, findable, entirely logical cause once you actually look, rather than being some mysterious exception to how CSS is supposed to behave.
Practice Questions
1. You inspect an element in dev tools and see two rules both setting color, neither struck through, but only one visually applies. Is this possible, and if so, why might both appear “active” in the panel?
Show Answer
This typically isn’t possible for the exact same property on the exact same element — if two rules both set color and neither shows struck through, they likely target different elements, or one is inherited rather than directly applied; dev tools inheritance display can sometimes look ambiguous at first glance, worth double-checking which element each rule actually targets.
2. What’s the very first debugging step recommended in this lesson, before even looking at specificity?
Show Answer
Confirming the element you’re inspecting is actually the one you think it is, not a wrapping container or a different nearby element.
3. A margin appears larger than expected on an element. Which specific dev tools feature, mentioned in this lesson, would help you confirm the actual computed value?
Show Answer
The computed box model diagram, which shows the actual real numbers the browser calculated for content, padding, border, and margin.
4. True or False: a struck-through rule in dev tools means that rule contains a syntax error.
Show Answer
False — struck-through means the rule is valid and was read, but overridden by something with equal or higher specificity; it has nothing to do with syntax errors.
5. Explain why reaching for !important immediately, without inspecting first, tends to hide the real problem rather than solve it.
Show Answer
Because it treats the symptom (the style not applying) rather than diagnosing the actual cause (something else winning the cascade) — the underlying conflict still exists, just now hidden behind a forced override that will itself need to be fought later if anyone needs to change that property again.
Try It Yourself
You inspect an element and see it has an unexpectedly large gap below it that you didn’t set directly. What box-model layer, from Part 1’s lesson, is the most likely cause, and how would dev tools help confirm it?
Show Answer
margin — dev tools’ box model diagram visually shows each layer’s actual computed value, letting you see margin causing the gap directly, rather than guessing.
Quick Check
1. What does a struck-through rule in dev tools actually mean?
Show Answer
The rule exists but is being overridden by something with equal or higher specificity.
2. What’s the recommended first debugging step before changing any CSS?
Show Answer
Actually inspecting the element in dev tools to observe what’s really happening.
3. Why is jumping straight to !important often the wrong first move?
Show Answer
It skips diagnosing the actual cause, and creates a harder-to-override rule for the future.
4. You inspect an element and see it has an unexpectedly large gap below it that you didn’t set directly. What box-model layer, from Part 1’s lesson, is the most likely cause, and how would dev tools help confirm it?
Show Answer
margin — dev tools’ box model diagram visually shows each layer’s actual computed value, letting you see margin causing the gap directly, rather than guessing.
5. A button’s background color isn’t changing despite your new CSS rule. You open dev tools and see your rule listed, but with a strikethrough through it. Before reading on: what does that specifically tell you, and what’s the next concrete thing to check?
Show Answer
A struck-through rule means it exists and was genuinely read by the browser, but something else with equal or higher specificity is winning instead, based on the exact cascade rules from Part 1. The next concrete step is checking which other rule is actually applying, usually visible right above or below the struck-through one in the same dev tools panel, and comparing their specificity directly, applying the cascade lesson as real debugging rather than just a written exercise.