Shadow DOM

Slap yourself if

You think Shadow DOM is just scoped CSS or believe it provides true isolation without tradeoffs.

Why this exists

Because Shadow DOM is often adopted for encapsulation and then blamed when styles don’t apply, events behave strangely, or debugging becomes hostile.

Mental model

Shadow DOM is an encapsulation boundary enforced by the browser’s DOM, style, and event systems — not a convenience layer. It changes how everything propagates.

  • A shadow root creates a separate DOM subtree with its own scope.
  • Styles are scoped by default and do not cross the boundary.
  • Event propagation is retargeted when crossing the shadow boundary.
  • The composed tree, not the DOM tree, determines what the user sees.
  • Assuming global CSS will style shadow content.
  • Breaking event delegation without realizing it.
  • Overusing closed shadow roots and killing debuggability.
  • Treating Shadow DOM as a drop-in replacement for BEM or CSS Modules.

Shadow DOM provides browser-enforced encapsulation for DOM, styles, and events, altering propagation and styling semantics rather than just scoping selectors.

  • Calls it iframe-like isolation.
  • Thinks events don’t bubble at all.
  • Ignores the composed tree.
  • Frames it as purely a CSS feature.

Deep dive

Requires Pro

Premium deep dives include more internals, more scars.

What the browser actually isolates — and what it doesn’t

Why your events stopped behaving normally

Styling power vs control loss

Why Shadow DOM makes bugs harder to see

When Shadow DOM is the wrong tool