Explain Shadow DOM, encapsulation, and event propagation

WHAT THIS TESTS: This question tests whether you understand browser-native encapsulation mechanisms rather than framework abstractions. Interviewers want to see that you know how the shadow boundary actually works, why it matters for reusable custom elements, and how events cross that boundary. Senior candidates should demonstrate familiarity with the platform primitives that frameworks build on top of.

A GOOD ANSWER COVERS: First, define the four key terms: the shadow host is the regular DOM element that hosts the shadow tree; the shadow root is the root node of the hidden tree; the shadow tree is the encapsulated DOM inside; and the shadow boundary is the line separating the shadow tree from the regular DOM. Second, explain style encapsulation: styles defined inside the shadow DOM do not leak out to the light DOM, and outside selectors do not pierce into the shadow DOM except for inheritable properties like color or font family and CSS custom properties. Third, explain DOM encapsulation: in open mode, JavaScript outside can access the shadow root via element.shadowRoot, while in closed mode it returns null, though closed mode is not a security boundary. Fourth, explain event propagation: events that originate inside the shadow DOM cross the shadow boundary during the bubbling or capturing phases, but their target is retargeted to the shadow host so that the internal structure remains hidden from listeners in the light DOM. Some events like slotchange do not bubble out at all.

COMMON WRONG ANSWERS: A major red flag is conflating Shadow DOM with the Virtual DOM used by React or with iframes. Another weak answer claims that closed mode provides security; it only provides encapsulation from accidental access, not malicious inspection. Saying that events cannot leave the shadow DOM is also incorrect because most events do bubble up, they just get retargeted. Finally, asserting that all CSS properties are blocked from the outside is wrong because inherited properties and CSS variables still flow through.

LIKELY FOLLOW-UPS: An interviewer might ask how slots compose light DOM children into the shadow tree and what happens with slotted content styling. They might also ask about the implications of closed mode for testing and accessibility tooling, or how to pierce encapsulation intentionally using CSS custom properties and events. Another common follow-up is comparing declarative shadow DOM to imperative attachment.

ONE CONCRETE EXAMPLE: Imagine you build a custom video player as a web component. You attach a shadow root to the host element and place buttons, a progress bar, and tooltips inside the shadow tree. A page-level CSS rule like button { background: red } does not affect your internal controls because the shadow boundary blocks it. When a user clicks an internal play button, a click event bubbles up past the shadow boundary into the light DOM, but document.addEventListener('click') sees the target as the custom video element itself, not the internal button, because the browser retargets the event. This keeps your internal implementation details hidden while still allowing the page to respond to user interaction.

Source: developer.mozilla.org