The Elements Panel

Concept

The Elements panel - called the Inspector in Firefox - shows the DOM the browser actually built. Not your source file. Not what the server sent. The live tree, after error recovery and after every script has run.

Debugging markup against view source is why some bugs appear impossible. The panel is the truth.

Opening it

On macOS substitute Cmd for Ctrl and add Option where the shortcut differs.

What you can do in it

Read the real tree

Expand and collapse nodes, and see exactly how the parser interpreted your markup. Write this:

<p>Total: <div>1,200</div></p>

and the panel shows an empty paragraph, a div beside it, and no trace of the closing tag you wrote. That is the answer to why the styling did not apply.

Edit live

• Double click a tag name, an attribute or text to change it.
• Right click a node for Edit as HTML, which opens the whole subtree for editing.
• Press Delete to remove a node, and Ctrl Z to undo.
• Drag nodes to reorder them.

Nothing here is saved. Reloading discards it, which makes it a safe scratchpad for trying a fix before writing it.

The Styles pane

Every rule matching the selected element, in cascade order, with overridden declarations struck through. Below it:

• Computed - the final value of every property, and which rule won.
• The box model diagram - margin, border, padding and content, with real numbers.
• Checkboxes beside each declaration to toggle it off and see what changes.

Force element state

The :hov button lets you pin :hover, :focus, :focus-visible, :active and :visited. This is the only sane way to inspect a hover state, since moving the mouse to the panel would otherwise cancel it.

The Accessibility pane

Select any element and read its computed accessible name, its role, its state and its position in the accessibility tree. This answers why is this button announced as just button in two seconds.

It also shows a contrast ratio for text, with a pass or fail against the guideline thresholds.

The colour picker

Click a colour swatch in the Styles pane and the picker shows the contrast ratio against the background, with the AA and AAA thresholds marked. Dragging the colour shows the ratio updating live - the fastest way to find a compliant shade.

Breakpoints on DOM changes

Right click a node, then Break on, and choose subtree modifications, attribute modifications or node removal. Execution pauses when a script touches it, and the call stack shows exactly which line did it.

This is the tool for something is changing this element and I cannot find what.

Copying things out

Right click a node for:

• Copy outerHTML - the element and its contents.
• Copy selector - a CSS selector that reaches it.
• Copy JS path - a document.querySelector call.
• Store as global variable - assigns it to temp1 in the console.

Also useful: $0 in the console always refers to the element currently selected in the panel, and $1 to the previously selected one.

$0                          // the selected element
$0.getBoundingClientRect()  // its size and position
$0.dataset                  // its data attributes
getEventListeners($0)       // what is listening to it (Chrome)

Device emulation

The device toolbar - Ctrl Shift M - lets you set an arbitrary viewport size, simulate touch, throttle the network and the processor, and take a full page screenshot.

It is genuinely useful and it is not a real device. Touch behaviour, browser interface height, real network variability and font rendering all differ. Test on hardware before shipping anything important.

Reading the rendered page differently

The Rendering panel, opened from the command menu, includes several switches worth knowing:

• Emulate prefers-color-scheme and prefers-reduced-motion.
• Emulate vision deficiencies, including several forms of colour blindness and blurred vision.
• Paint flashing, which highlights areas being repainted.
• Layout shift regions, which highlights content that moved.

The vision deficiency emulation is the fastest way to check whether a status indicator relies on colour alone.

Important rules

• The panel shows the DOM, not your file. They differ whenever markup was repaired or a script ran.
• Edits are temporary and lost on reload.
• Struck through declarations in the Styles pane were overridden.
• The Computed tab shows what actually applied.
• Device emulation approximates; it does not replace a device.

Common mistakes

• Debugging against view source rather than the live tree.
• Editing in the panel and forgetting to make the same change in the file.
• Missing that a declaration is struck through and concluding CSS is broken.
• Not knowing about state forcing, and trying to inspect a hover state by hand.
• Ignoring the Accessibility pane, then wondering why a control is announced oddly.
• Testing responsiveness only in emulation.

Best practices

• Inspect first, guess second.
• Use state forcing for hover and focus styles.
• Check the accessible name of every icon control.
• Use the colour picker contrast readout while choosing colours.
• Use DOM breakpoints to find the script changing something.
• Learn the command menu; it reaches every panel by name.

Practice

1. Write <p>Total: <div>1,200</div></p> and compare the panel with view source.
2. Force :hover on a button and inspect its styles without moving the mouse.
3. Read the accessible name of five controls on a page you built.
4. Set a DOM breakpoint on attribute changes and find the script that toggles a class.