A custom element <my-card> renders <slot></slot> in its shadow root, and the page writes <my-card><span>Hi</span></my-card>. After slotting, where does that <span> live in the DOM, and which of document.querySelector, host.querySelector and shadowRoot.querySelector find it?

## Three trees, one of which is not a DOM tree When a host element has a shadow root and slotted content, three structures are in play: 1. **The document tree (light DOM).** `<my-card>` with its `<span>` child, exactly as the page author wrote it. This is the tree every ordinary DOM API walks. 2. **The shadow tree.** What the component built: wrappers, a `<style>`, and `<slot>` elements. Its root is the `ShadowRoot`. 3. **The flattened tree.** A composed view in which every `<slot>` is replaced by the nodes assigned to it. This is what the browser lays out and paints — and it is not something you traverse with `querySelector`. Slotting affects only the third. No node is reparented, no node changes owner document. ## What each query sees ```js const host = document.querySelector('my-card'); host.querySelector('span'); // the <span> (light DOM child) document.querySelector('my-card span');// the <span> host.shadowRoot.querySelector('span'); // null host.shadowRoot.querySelector('slot'); // the <slot> span.parentNode === host; // true span.parentNode === slot; // false ``` The mirror-image rule matters just as much: `document.querySelector` cannot reach *into* the shadow tree. The two directions together are the whole model — the caller's content stays public and reachable; the component's own markup stays private behind `shadowRoot`. ## The assignment relation, from both ends The platform exposes the projection explicitly rather than making you infer it: ```js const slot = host.shadowRoot.querySelector('slot'); slot.assignedNodes(); // [ #text?, <span>, ... ] nodes, text included slot.assignedElements(); // [ <span> ] elements only slot.assignedNodes({ flatten: true }); // fallback content if nothing is assigned, // and chained slots resolved through span.assignedSlot; // the <slot> element, or null when unassigned ``` `assignedElements()` is usually what component code wants, because `assignedNodes()` includes the whitespace text nodes produced by formatted markup. `{ flatten: true }` answers a different question: "what will actually render here", which is why it substitutes fallback content for an empty slot and resolves a slot that has itself been assigned to another slot. ## Consequences that show up in real code **Reading caller content.** A component inspects what it was given through its own light DOM — `this.querySelectorAll('my-tab')` — or through `slot.assignedElements()`. Reaching through the shadow root returns nothing and is the single most common confusion here. **Ownership of behaviour.** Because slotted nodes are the page's nodes, the page can also mutate them at any time, and it does not need the component's permission. A component that caches a reference to a slotted child is caching something someone else owns; the assignment API plus the slot's `slotchange` event exist precisely so it can re-read instead. **Styling.** The nodes are in the document tree, so document stylesheets match them normally — a page rule `my-card span { color: red }` applies. The component's ability to style them from inside the shadow tree is deliberately narrower, and is a topic in its own right. **Events.** A `click` on the slotted `<span>` starts on a node in the light DOM, but propagation follows the flattened tree, so the path runs through the slot and the shadow root before continuing up the host's ancestors. The details of what `event.target` looks like from outside the boundary belong to shadow-DOM encapsulation; the point for slotting is only that the path is the composed one, not the plain light-DOM one. ## How to say it in an interview A compact, correct formulation: "Slotted content is the caller's content and stays in the caller's tree. The component gets to decide *where* it renders, not *who owns it*. `querySelector` follows ownership; rendering follows the flattened tree; `assignedNodes` and `assignedSlot` are how you cross between the two." That framing also explains the API's limits — a component cannot rewrite or reorder what it is handed the way a render-time library can clone and transform children. It can only route it, provide fallbacks, and react when the assignment changes.