やあ、お疲れ様。
最近、コンポーネント設計の話題になると必ず名前が挙がる「Shadow DOM」だけど、君はちゃんとその中身を理解して使いこなせているかい？
「いや、なんとなくWeb ComponentsのスコープドCSSを作るためのものでしょ？」なんて思っているなら、今日の話をぜひ聞いてほしい。実務で大規模なアプリケーションをメンテしていると、「なぜかグローバルのスタイルが漏れ出す」「モーダルの裏でレイアウトが崩れる」といった泥臭いトラブルに直面する。その根源を断つためには、ブラウザが裏側でHTMLをどう解釈し、どうやってDOMツリーとShadow DOMを「合体（コンポジション）」させているのか、そのメカニズムを解剖しておく必要があるんだ。
今日は、ブラウザのレンダリングパイプラインの裏側を覗きながら、Shadow DOMがどのようにカプセル化を実現しているのか、プロの視点で徹底的に解説しよう。
—
1. ブラウザは裏側で何をしているのか？ Shadow DOMのレンダリング統合メカニズム
私たちが普段書くHTMLは、ブラウザによってパースされ、1つの巨大な「DOMツリー」へと組み立てられる。これは基本だよね。しかし、Web Components（Custom Elements）の登場により、DOMツリーの中に「隠された小さな別世界」を作れるようになった。これが Shadow DOM だ。
メインツリーとシャドウツリーの出会い：合体（Compositing）
ブラウザのレンダリングエンジン（BlinkやWebKitなど）の視点で見ると、Shadow DOMはメインのDOMツリー（Light DOM）とは完全に独立した別のツリーとして構築される。
では、画面を描画する際、ブラウザはこの2つのツリーをどうやって結合しているのか？
ここで登場するのが、ブラウザ内部での「Shadow Root」と「Slot（スロット）」のメカニズムだ。
1. カプセル化の壁（Shadow Boundary）
Shadow Rootの内部にある要素は、外側のメインDOM（Light DOM）のセレクタからは基本的に見えない。これが強力なスタイルのカプセル化を生む。
2. 描画時の投影（Projection）
シャドウツリーの中に `
つまり、ブラウザはパースの段階ではツリーを完全に分離して扱い、レイアウトやペイントの直前の段階で、スロットを介して視覚的なツリーを再構築している。この「構造の分離」と「描画の統合」の合わせ技こそが、Shadow DOMの真髄なのさ。
—
2. スタイルとレイアウトの分離：スコープはどう守られているのか？
実務で一番ハマるのが「スタイルが効かない！」「どこからかCSSが漏れてきた！」という現象だ。
スタイルのカプセル化の正体
Shadow DOM内の `
Shadow DOM カプセル化のデモ
これはグローバルCSS（赤色）が直撃する通常の段落です。
最近、ブラウザのソースコードリーディングにハマっています。