In the browser rendering pipeline, how do the CSS declarations `display: none` and `visibility: hidden` differ in whether the element gets a box, whether it occupies space, and what work the browser redoes when you switch each one back on?

## Two different stages To put pixels on screen the browser resolves a computed style for every element, combines the DOM with those styles into a **render tree** of boxes, runs **layout** to give each box a size and position, **paints** the boxes, and composites the result. `display` is consulted when the render tree is built — it decides whether a box exists. `visibility` is consulted at paint time — the box exists and has already been laid out, and the browser just does not draw it. That one-sentence difference explains everything else. ## display: none The element and every descendant generate no boxes: - **No space.** Siblings move up to fill the gap; the parent's auto height shrinks. - **No paint, no hit testing.** Pointer events cannot reach it because there is no box to hit. - **Removed from the accessibility tree**, so screen readers do not announce it, and it is skipped by find-in-page. - **Geometry queries report zeros.** With no box there is nothing to measure, which is why measuring a hidden element before showing it fails. - **Descendants cannot opt out.** `display` is not inherited, but a child of a box-less element still has no parent box to live in, so declaring `display: block` on it changes nothing. - Revealing it is the expensive direction: the browser must construct boxes for the subtree and lay them out, and the surrounding content moves. One useful side effect: a `background-image` on an element that generates no box is generally not fetched, while an `<img>` element's `src` is fetched regardless of whether it renders. The HTML `hidden` attribute is not a separate mechanism — the user-agent stylesheet simply maps it to `display: none`, which is why a page rule with `display: block` silently overrides it. ## visibility: hidden The box is created, laid out, sized and positioned exactly as if it were visible. It reserves its space, contributes to the parent's height and to scrollable overflow, and then paint skips it. It is not hit-testable and it is hidden from the accessibility tree, so it is invisible to both the mouse and a screen reader while remaining a real participant in geometry. Because `visibility` is an inherited property, a descendant can set `visibility: visible` and paint through a hidden ancestor — a genuine capability, not a bug: ```css .panel { visibility: hidden; } .panel .badge { visibility: visible; } ``` On table rows and columns there is a third value, `visibility: collapse`, which removes the row or column much as `display: none` would; elsewhere it behaves like `hidden`. ## opacity: 0 is not the same thing `opacity: 0` keeps the box, keeps the space, **and keeps hit testing** — the element still receives clicks and is still exposed to assistive technology. An invisible element that swallows clicks is almost always an `opacity: 0` element that should have been `visibility: hidden`. ## content-visibility sits between them `content-visibility: hidden` skips the element's contents the way `display: none` does, but keeps the element's own box and preserves the rendering state of the skipped subtree, so showing it again is much cheaper than rebuilding it. Its contents are not reachable by find-in-page while hidden. ## Choosing Hide something without letting the page jump — a spinner slot, a placeholder that must hold its size — with `visibility: hidden`. Remove something from the flow, such as a collapsed section or an inactive tab panel, with `display: none`. For a large subtree you will show and hide repeatedly and want fast re-show, reach for `content-visibility: hidden`. And if the goal is animating something away, remember that `display` and `visibility` were not designed as animation targets the way `opacity` is.