Debugging Layouts with Developer Tools

A seven-step routine for "why does it look like that?", using the Computed pane, the box model diagram, the flex and grid overlays, switching rules off, forcing :hover and :focus, and the outline trick.

Journeyman · CSS · Web Development · Updated

After this lesson you can

  • Read an element's final values in the Computed pane and trace each one back to the rule that set it
  • Use the box model diagram and the flex and grid overlays to see why an element is the size and place it is
  • Narrow down a layout bug by switching declarations off, forcing :hover and :focus, and outlining every box

Key takeaways

  • The Styles pane shows every rule that tried to style an element. The Computed pane shows the final value of each property, and which rule set it.
  • The box model diagram shows an element's content, padding, border and margin in pixels, so you can see where unexpected space comes from.
  • The flex and grid badges in the Elements panel draw a layout's lines, gaps and tracks on the page.
  • Switch declarations off one at a time, and force :hover or :focus, to find the one rule behind a problem.
    • { outline: 1px solid red; } draws a line around every box without moving anything, so the box that sticks out shows itself.

Weekend Kitchen is a recipe blog, and its post for Slow Sunday Shakshuka looks fine on a laptop. On a phone, the shopping list and the photo of the pan are both cut off at the right edge, and the ingredients are squeezed into a thin column. You'll meet pages like this all the time: a teammate's page in a group project, a site you've been asked to fix by Friday, your own page the morning after. Guessing at the cause can eat an evening. A routine finds it in minutes, and the developer tools hold every step of it.

This lesson builds on Look Inside Any Page with Developer Tools, where you opened the tools and read the Styles pane. The steps here are named as Chrome and Edge name them, with Firefox's names beside them.

A routine for "why does it look like that?"

A good mechanic doesn't replace parts at random. They look, they measure, and they test one thing at a time. Debugging CSS works the same way, in seven steps:

  1. Inspect the element that looks wrong (right-click it, Inspect).
  2. Read the final values in the Computed pane.
  3. Look at its box: content, padding, border and margin.
  4. Show its layout: the flex or grid lines it sits in.
  5. Switch declarations off, one at a time.
  6. Force its state, such as :hover or :focus.
  7. Outline every box, when you can't tell which element is the problem.

You won't need all seven every time. Most bugs give themselves up by step 3. The rest of this lesson takes each step in turn, on the shakshuka post.

The Computed pane: what the browser ended up with

The Styles pane is like a courtroom: every rule that wants to style the element makes its case, and the losers are crossed out. The Computed pane is the verdict. It lists each property once, with the final value the browser is using. That final value is the computed value, after the browser has done the math: 1.25rem becomes 20px, and a percentage becomes pixels.

Here's the rule for the post's introduction:

.post-intro {
  font-size: 1.25rem;
  max-width: 40rem;
  margin: 0 auto 2rem;
}

Inspect the introduction and click Computed, beside Styles (Firefox: Computed, in the side panel of the Inspector). Type font-size in its filter box, and you'll see 20px. Click the small arrow beside the property, and it lists every rule that set it, the winner first, each with its file and line. Click that link, and you jump to the rule. When a value surprises you, this is how you find out where it came from in seconds, even in a stylesheet thousands of lines long.

Try it. Open any page you use, inspect a heading, and find its font-size and color in the Computed pane. Expand each one: which rule won?

The box model diagram: where did that space come from?

Every element is a box: content in the middle, then padding, then a border, then margin outside it. At the top of the Computed pane (Firefox: the Layout panel, under Box Model), the developer tools draw that box with the real numbers in each ring. Point at a ring, and the page highlights that part: content in blue, padding in green, margin in orange.

On the shakshuka post, there's a large gap above the post's title, and nobody wrote a margin for it. The title's rule looks harmless:

.post-title {
  font-size: 2rem;
  line-height: 1.2;
}

Inspect the title and point at the diagram's margin ring: a band of orange appears above the title. The rule above sets no margin, so the margin comes from the browser's own styles for <h1> (in the Styles pane they're marked user agent stylesheet). The diagram showed you the size of the space, and the Styles pane showed you who put it there.

The Computed pane for Weekend Kitchen's post title: the box model diagram at the top with its margin ring highlighted, and the same orange band shown above the title on the page

Flex and grid overlays: seeing the layout

A flex or grid layout has lines you can't see: columns, rows and the gaps between them. In the Elements panel, an element that is a flex container has a small flex badge beside it, and a grid container has a grid badge (Firefox shows the same badges). Click the badge, and the browser draws its layout on top of the page: each column, each gap, and the size of each track.

Weekend Kitchen's ingredients sit in a grid:

.ingredients {
  display: grid;
  grid-template-columns: repeat(3, 1fr);
  gap: 1rem;
}

Click its grid badge on a phone-sized window, and the overlay shows three columns of about 100 pixels each, with words such as coriander squeezed into them. Three columns is too many for a phone. The Layout tab beside Styles (Firefox: the Layout panel) lists every grid and flex container on the page, with checkboxes to show their overlays and options such as line numbers and track sizes.

To see the page at a phone's width, open the device toolbar with Ctrl+Shift+M (Cmd+Shift+M on a Mac), or the phone icon at the top left of the tools. Firefox calls it Responsive Design Mode, with the same keys on Windows and Cmd+Option+M on a Mac.

Switch declarations off, and force a state

When you don't know which declaration causes a problem, switch them off one at a time. Point at a declaration in the Styles pane, and untick the checkbox beside it. If the problem goes away, you've found it; tick it back on, and try the next one. With many declarations, switch off half at once: if the bug stays, it's in the other half. That's the quickest way to search a long rule.

Look out for a declaration that's dimmed with a small i beside it. It isn't crossed out, so nothing beat it, but it does nothing here. Point at the i, and the tools tell you why, for example that z-index has no effect on an element that isn't positioned. Firefox and Chrome both show these.

Some styles only apply in a state, such as the mouse over a button. Weekend Kitchen's Jump to recipe button turns hard to read on hover, but the moment you move the mouse to the developer tools, the hover is gone:

.jump-button:hover {
  background-color: #f6c453;
  color: #f8f1e5;
}

Click :hov at the top of the Styles pane (Firefox: :hov in the Rules pane), and tick :hover. The button stays in its hover state while you work, so you can read its rules and try a darker text color. The same list forces :focus, :focus-visible and :active. A pseudo-class is the name for these states, written with one colon.

The outline trick: show every box

Sometimes the problem is that something on the page is wider than it should be, and you can't tell what. Add this rule at the end of the stylesheet, or type it into the Styles pane with the + button (Firefox has the same button):

* {
  outline: 1px solid red;
}

The * (read "star") is the universal selector: it picks every element. Now each box on the page has a thin red line around it, and the one box that runs past the right edge of the screen stands out.

It's outline and not border for a reason. An outline is drawn outside the box and takes up no space, so the layout you're investigating doesn't change. A border adds a pixel on every side of every box, and that can create a bug of its own while you look for the first one. Delete the rule when you're done.

Try it. Open a page with a sideways scroll, or make one: give an element width: 800px and view it in the device toolbar at a phone's width. Add the outline rule, and find the box that sticks out. In Firefox, the Inspector also marks the element that causes the scroll with an overflow badge.

Check yourself

2 questions to try on the lesson page.

So what

A routine turns "it looks broken" into a list of facts: this value, from this rule, on this box, in this state. With those facts, the fix is usually one line, and the next lesson, Common Layout Bugs and How to Fix Them, shows the bugs this routine finds most often.

Key terms

Cheat sheets

Related