What is the render tree that a browser builds before layout, how does it relate to the DOM tree, and which parts of the document never appear in it?

## What the tree is The DOM is a tree of *nodes* — a faithful model of the document's structure. Layout does not operate on nodes; it operates on **boxes**. So once the DOM exists and style resolution has produced a computed style for every element, the browser builds a second structure, commonly called the render tree (engines name it the layout tree or the box tree), whose entries are the boxes to be sized, positioned, painted and hit-tested. Interviewers ask about it because most people assume it mirrors the DOM. It does not, in four distinct ways. ## 1. Nodes that produce no box - Everything inside `<head>` — `<title>`, `<meta>`, `<link>`, `<script>`, `<style>`. These are in the DOM and reachable from script, but they render nothing. - Comment nodes, and `<script>`/`<template>` content in the body. A `<template>`'s contents live in a separate inert document fragment and are never rendered until cloned into the document. - Any element with `display: none`, together with its entire subtree. - Whitespace-only text between block-level elements, which usually produces no text box. Note what is *not* on that list: `visibility: hidden` elements are in the render tree. They are laid out and take up space; only paint skips them. ## 2. Boxes that have no node The reverse direction also breaks. `::before` and `::after` generate boxes when a `content` value is set, and those boxes have no DOM node — which is exactly why `document.querySelector` cannot select them and why you read their styles with the second argument of `getComputedStyle`. List items generate a marker box. Anonymous boxes appear where the box tree needs structure the markup does not provide: put raw text next to a block child inside a block container and the text is wrapped in an anonymous block box so the container holds only blocks. ## 3. One element, many boxes A node maps to a box only in the simple case. An inline element whose text wraps over three lines contributes one fragment per line. An element inside a multi-column container fragments across columns. So "the number of boxes" is a property of layout, not of the markup. ## 4. display: contents `display: contents` is the mirror image of `display: none`: the element itself generates no box, but its children generate theirs and are laid out as if they were direct children of the element's parent. It is the tool for letting a wrapper element vanish from a flex or grid layout while remaining in the DOM. ```css .wrapper { display: contents; } /* children become grid items of the grandparent */ ``` Be careful with it: removing a box can also remove semantics that browsers derived from that box, so it is not a free abstraction on elements with meaning of their own. ## Shadow DOM and the flat tree When shadow roots are involved, the browser does not lay out the DOM tree as authored. It computes the **flat tree**: for each shadow host, the shadow root's children replace the host's children, and light-DOM nodes assigned to a `<slot>` appear at the slot's position. Boxes are generated from that flattened structure, which is why slotted content inherits from and is laid out inside the shadow markup even though `parentNode` still reports the original light-DOM parent. ## Why the distinction pays off Once you see the render tree as a separate structure, several everyday behaviours stop being surprising: a `display: none` element measures as zero because it has no box; toggling `display` is more expensive than toggling `visibility` because boxes must be constructed; and a style change that only affects a paint-time property does not need the box tree rebuilt at all. It also frames the next stage cleanly — layout is simply the traversal that gives each of these boxes a size and a position.