Reading What the Browser Actually Did
Every browser ships a tool that shows you the live page, every rule applied to any element, and which ones were crossed out and why. Most beginners never open it, and it answers nearly every question they ask.
Read first: Why Your Rule Did Not Apply
Every browser ships a tool that shows you the live page, every rule applied to any element, and which ones were crossed out and why. Most beginners never open it, and it answers nearly every question they ask.
Inspect element shows the live tree, not your file
Right-click anything on any page and choose Inspect. Or press F12, or Ctrl/Cmd + Shift + I.
The Elements panel is the DOM from chapter 5 — the tree the browser built, live, right now. It is not your HTML file, and that distinction matters more than it sounds.
The bytes the server sent. What you wrote.
The tree as it exists now, including anything the browser corrected and anything JavaScript changed since.
A tag you forgot to close appears closed here, in whatever place the browser decided. That difference is the bug.
Hover any node and the browser highlights it on the page, with its box model shaded — content, padding, border, and margin in four colours. That overlay alone explains most "why is there a gap there" questions in about two seconds.
The styles panel lists every rule, in order
With an element selected, the Styles panel on the right lists every rule that matched it — in cascade order, with the winning rules at the top and the file and line number each came from.
element.style { } ← inline style attribute, if any .project:hover styles.css:142 border-color: var(--accent); .project styles.css:128 padding: 1.5rem; background: var(--raised); border-radius: 8px; li styles.css:44 max-width: 65ch; Inherited from section body styles.css:31 line-height: 1.6; color: var(--ink);Four things in that list explain most of the panel's behaviour.
Click it and devtools opens that exact line in the Sources panel. This is how you find which of four stylesheets a rule came from.
Top of the list wins. It is the cascade from chapter 13, rendered as a list you can read.
A separate section at the bottom for values that came down the tree rather than from a rule targeting this element. Chapter 13's other mechanism, labelled.
The browser's own defaults, shown as a source like any other. This is where you can actually read them.
The Computed tab beside it answers a different question: not which rules matched, but what the final value of every property ended up being. When you want to know what the font size actually is, after everything, that is the tab.
A crossed-out declaration tells you it lost
This is one of the most useful devtools habits and the reason chapter 13 ends by pointing here. When a declaration is overridden, devtools draws a line through it.
#sidebar .card site.css:88 background: white; .card styles.css:210 background: hotpink; ← struck throughYou wrote the pink one, it is later in the file, and it lost. The struck-through line tells you it lost; the rule above it tells you what to. #sidebar .card is 1-1-0 and yours is 0-1-0, so specificity decided it before source order was ever consulted.
Hovering a struck-through declaration usually explains why. Three reasons cover almost everything:
A more specific rule won. The winner is somewhere above it in the same list.
Struck through as well, but with a warning icon beside it. A typo, or a value the property does not accept.
Valid, matched, and meaningless for this element — width on an inline element from chapter 16. Devtools often does NOT flag this one, which is why chapter 16 exists.
Editing in devtools changes nothing on disk
Everything in the Styles panel is editable. Click a value and type a new one; click the blank space in a rule and add a declaration; tick and untick the checkbox beside any declaration to toggle it.
Changes appear instantly and are lost on refresh. Nothing touches your files. That makes it the ideal place to experiment: try six values in ten seconds, then write the one that worked into your stylesheet.
With the cursor in a numeric value, Up and Down nudge by 1. Shift+Up moves by 10, Alt/Option+Up by 0.1. Excellent for finding a spacing value by feel.
A button at the top of the Styles panel that force-applies :hover, :focus, or :active — so you can style a hover state while actually looking at it.
Click one for a picker and an eyedropper. Shift-click the swatch to cycle between hex, rgb, and hsl.
The + button creates a new rule for the current element, which you can then copy into your file.
The device toolbar and the network tab
Two more panels earn their place for the work in this track.
The device toolbar — the phone-and-tablet icon, or Ctrl/Cmd + Shift + M — simulates a narrow viewport with touch input and a device pixel ratio. Presets are there, and the more useful thing is the Responsive mode where you drag the edge: every layout problem announces itself somewhere between 1400 and 320 pixels, and you find breakpoints you would not have guessed.
The Network tab lists every file the page requested, with its status code. Refresh with it open, and two questions get answered immediately:
Your stylesheet, image, or font is not where the page thinks it is. This is the answer to "why is my page unstyled" essentially every time — a path problem, not a CSS problem.
Sort by size. An unresized phone photo at 4 MB will be at the top, and it is why the page feels slow.
A checkbox at the top. Tick it while devtools is open so a hard refresh is not needed after every CSS change.
Devtools habits worth having by the end of this track
- ✓Ctrl/Cmd + Shift + C, click the thing, read its styles — before guessing
- ✓Look for the strike-through when a rule does not apply
- ✓Read the box model overlay when spacing is wrong
- ✓Nudge values with the arrow keys instead of editing, saving, and refreshing
- ✓Drag the responsive width from wide to narrow before calling a layout done
- ✓Check the network tab for a red 404 whenever something is mysteriously missing
- ✓Run the Lighthouse tab on a finished page — it audits accessibility, performance, and SEO in one click
Key takeaways
- Ctrl/Cmd + Shift + I opens devtools; Ctrl/Cmd + Shift + C picks an element directly.
- The Elements panel is the live DOM, not your file — a tag you forgot to close appears closed, wherever the browser decided.
- Hovering a node shades its box model on the page, which explains most unexplained gaps.
- The Styles panel lists every matching rule in cascade order with its file and line.
- "Inherited from" is a separate section, because inheritance is a separate mechanism.
- A struck-through declaration lost. The rule that beat it is above it in the same list.
- The Computed tab answers what the final value is, rather than which rules matched.
- Devtools edits are live and lost on refresh — ideal for experimenting, and copy the result into your file.
- Arrow keys nudge numeric values; the :hov button force-applies hover and focus states.
- The responsive device toolbar is for dragging, not for presets.
- A red 404 in the network tab is the answer to "why is my page unstyled" nearly every time.
- Firefox's grid and flexbox inspectors overlay the tracks on the page, which is worth switching browsers for.
Before you move on
Quick check
Answer these to unlock the next chapter: 3 of 4 to pass. You can retake it anytime.
Make a free account to read on
Every chapter is free — an account lets your course progress follow you from your laptop to your phone. No payment, no trial.