Changing one element's height sometimes relayouts only that element's subtree and sometimes the whole document. What decides the scope of a reflow, and which page structures widen it?

## Dirty bits travel upward Browsers do not lay out the whole page on every change. Each change marks affected boxes as needing layout and propagates that mark up through their ancestors; at the next rendering opportunity the engine starts laying out at the highest marked box. Everything about reflow cost follows from how high that mark climbs. Ask one question about any change: **can this alter the geometry of anything outside the element?** If yes, the parent is dirty too, and you repeat the question one level up. ## When the mark stops: relayout boundaries The mark can stop at an element when re-laying out its interior provably cannot change anything outside it. Roughly, that requires: - the element's own used width and height are **definite** — fixed lengths, not `auto`, and not percentages whose resolution could shift; - its contents cannot leak out — it is a scroll container or otherwise clips, so growing content changes its scrollable overflow rather than pushing ancestors around; - it is a block-level box in a straightforward formatting context — not an inline box whose fragments live inside someone else's line boxes, and not a table cell, whose width is negotiated with the whole table. Engines call such an element a relayout boundary and restart layout there. The important consequence: a change deep inside a fixed-size, scrollable panel is cheap, while the same change inside an auto-sized wrapper is not. ## What widens the scope **Content-dependent sizing.** This is the main culprit. Any ancestor with `height: auto` gets its height from its children, so a child growing changes the parent, which changes *its* parent. Shrink-to-fit widths (floats, absolutely positioned boxes with `auto` width, inline-blocks) behave the same way horizontally, as do intrinsic grid tracks (`auto`, `min-content`, `max-content`) and flex items sized from content. **In-flow siblings.** Even when the mark stops climbing, it spreads sideways: a box that grows taller pushes every following in-flow sibling down, and line-level changes reflow the rest of the line and often the paragraph. **Auto-layout tables.** With `table-layout: auto` the browser must measure every cell before it can assign column widths, so a change in one cell can resize the whole table. `table-layout: fixed` bounds that by taking column widths from the first row. **Root-level scrollbar changes.** When document content crosses the viewport height and a classic scrollbar appears, the viewport gets narrower, so every percentage width, every viewport unit and every line break in the document is recomputed. `scrollbar-gutter: stable` reserves the space so this cannot oscillate. **Root font size.** Changing `font-size` on the root element invalidates every length expressed in `rem`, which in a modern codebase is most of them. ## Declaring a boundary instead of hoping for one Rather than relying on a box happening to satisfy the conditions above, you can state the guarantee: ```css .panel { contain: layout size; /* interior layout cannot affect the outside */ contain-intrinsic-size: 0 480px; } ``` That is a promise the engine can enforce, and it is what turns a large, frequently-mutating widget into a bounded unit. ## Applying it while debugging When a page gets slow as it grows, the question is rarely "which line triggered layout" — it is "how many boxes did that layout have to visit". Look for the auto-sized chain from the mutation site to the root, the sibling list that shifts after it, and any table or root-scroller involvement. Fixing the scope — giving the container a definite size, making it a scroll container, or containing it — usually beats trying to mutate less. It is also why a long list of items with a fixed-size row template stays affordable while the same list with content-sized rows degrades as it grows.