What do the CSS `contain` property and `content-visibility: auto` promise the browser's layout engine, and what do you give up in exchange?

## The bargain Layout is expensive because in general the engine cannot know whether a change inside a subtree affects the outside — an auto-height parent depends on its children, a wide cell resizes a table, overflowing content reaches ancestors. CSS containment lets you assert that it does not, and having that assertion, the engine can bound its work. ## The containment types - **`contain: layout`** — the element's internal layout is isolated: nothing inside can affect the geometry of boxes outside, and outside boxes cannot reach in. The element establishes an independent formatting context (so floats and margins do not cross it), becomes a stacking context, and becomes the containing block for `position: absolute` and `position: fixed` descendants. - **`contain: size`** — the element is sized as if it had no contents. Its own dimensions no longer depend on what is inside, which is the strongest possible cut in the dependency chain. Without an explicit size or `contain-intrinsic-size`, it collapses to zero in the contained dimension. - **`contain: inline-size`** — size containment on the inline axis only, so the element still grows in the block direction from its content. This is the well-behaved variant, and the same machinery underpins container queries. - **`contain: paint`** — descendants are clipped to the element's padding box and nothing paints outside it. Also creates a stacking context, an independent formatting context, and a containing block for positioned descendants. Off-screen contained elements need not be painted at all. - **`contain: style`** — scopes counter and quote effects so they cannot escape the subtree. Two shorthands: `content` applies layout, paint and style containment (everything except size), and `strict` adds size containment as well. `content` is usually what you want, because size containment is the one that needs a size supplied. ## content-visibility `content-visibility: auto` builds on containment: the element applies layout, style and paint containment, and while the browser decides its contents are not relevant to the user — far off-screen — it also applies size containment and **skips rendering the contents entirely**: no layout, no paint for the subtree. Scroll it into view and rendering resumes. `content-visibility: hidden` skips the contents unconditionally, like `display: none` for the subtree, while keeping its rendering state so re-showing is cheap. The partner property is `contain-intrinsic-size`, the placeholder size used while contents are skipped: ```css .row { content-visibility: auto; contain-intrinsic-size: auto 120px; /* remember the real size once measured */ } ``` The `auto` keyword tells the browser to remember the last actually-rendered size and use that instead of the guess once it has one. As of 2026 `content-visibility` is available across the major engines — Chromium shipped it in 2020, Firefox and Safari during 2024 — so the historical caveat is about older browsers, where it degrades to rendering everything. ## What it costs you **Layout surprises.** Adding `contain: layout` or `paint` to an existing component is not visually neutral: becoming a containing block re-anchors `position: fixed` descendants (a modal inside now pins to the panel, not the viewport), becoming a stacking context changes what can paint above what, and paint containment clips a dropdown that used to overflow. **Collapsed boxes.** Size containment without `contain-intrinsic-size` gives you a zero-height element, which is the most common first encounter with `contain: strict`. **Scroll accuracy.** With `content-visibility: auto`, the scrollbar length is computed from estimates for everything not yet rendered. Bad estimates make the scrollbar and scroll position shift as content is realised, and jumping to the bottom of a long list can land in the wrong place. **Findability.** Content skipped by `content-visibility: auto` remains reachable — find-in-page, focus navigation and accessibility make a subtree relevant to the user, which forces it to render. Content under `content-visibility: hidden` does not; treat it as hidden in every sense. ## Choosing Apply containment where a component is genuinely self-contained and mutates a lot — a chat pane, a virtualised table body, an editor canvas. Prefer `content` over `strict` unless you can state a size. Use `content-visibility: auto` for long, homogeneous lists whose row height you can estimate, and measure: on short pages the bookkeeping can cost more than it saves.