Web ComponentsとTailwind CSSの併用が難しい理由を少し深掘りする

再生速度

AI が生成した要約です。正確な内容は本文をご確認ください。

要約を読む

Web ComponentsとTailwind CSSを併用すると、スタイルが全く適用されないという問題があります。その結果、コンポーネントの見た目が予期しないようになり、開発が進まないケースが多数見られます。この問題の核心は、Shadow DOMとTailwindのスタイル仕組みが根本的に衝突している点です。 Shadow DOMは、コンポーネントの内部スタイルを外部から隔離する仕組みです。その結果、Shadow DOM内の要素に適用されるスタイルは、外部のCSSルールに影響されません。これにより、コンポーネントの見た目が外部のデザインに汚染されないようになります。 Tailwind CSSは、HTMLにクラスを書くだけで、グローバルなスタイルシートを自動生成します。そのCSSは、すべてのページに適用されるため、ページ全体にスタイルが行き渡ります。このグローバルなスタイルが、Shadow DOMの境界を越えられず、内部に適用されません。その結果、TailwindのクラスがShadow DOM内の要素に反映されないため、見た目が正しく表示されません。この問題は、Tailwind v4でも解決されず、基本的な仕組みが変わらないため、v4でも同じ問題が残ります。回避策として、TailwindのCSSを手動でコピーしてShadow DOM内に埋め込む方法があります。しかし、これだと各コンポーネントでCSSが重複し、メンテナンスが困難です。また、JITコンパイルのメリットも失われ、開発効率が下がります。もう一つの選択は、Shadow DOMを使わず、Light DOMに要素を配置することです。これならTailwindのスタイルが適用されますが、コンポーネントのスタイルが外部に漏れ出るため、独立性が失われます。結論として、Web ComponentsとTailwind CSSは併用すべきではありません。なぜなら、どちらの技術もスタイルの思想が異なっており、根本的に矛盾しているからです。このため、どちらかのメリットを大きく損なう結果になります。

 はじめにこんにちは！

KINTOテクノロジーズのプロジェクト推進グループでWebエンジニアをしている亀山です。

フロントエンドを勉強中です。
モダンなWeb開発においてはコンポーネント指向が主流となっています。UIを再利用可能な部品に分割することで、開発効率や保守性が向上します。Web ComponentsとTailwind CSSは、どちらもコンポーネント指向のフロントエンド開発を支援する強力なツールです。
Web Componentsは、標準仕様に基づいてカプセル化された再利用可能なカスタム要素を作成できる近年注目を集めている技術です。一方、Tailwind CSSは、ユーティリティファーストのアプローチで高速なUIスタイリングを実現するCSSフレームワークです。最近だとTailwind CSSもパフォーマンスが向上したv4が登場しておりアップデートも活発です。
一見すると、これらの技術は相性が良いように思えるかもしれません。「コンポーネントごとにカプセル化されたマークアップとロジック（Web Components）に、ユーティリティクラスで手軽にスタイルを当てる（Tailwind CSS）」という組み合わせは魅力的、、、だと思っていました。
いざ開発を始めると、どうしてもうまくいかない。調べていくとWeb Componentsの根幹をなすShadow DOMと、Tailwind CSSのスタイリングメカニズムには、お互いの根本的な思想が衝突していることがわかりました。本記事では、特にShadow DOMの観点から、両者がなぜ相性が悪いのか、そしてなぜ併用するべきではないのか私が勉強したことをまとめていきます。
 Web Componentsについて Shadow DOMとは何ぞやまずWeb Componentsは主に以下の3つの技術から構成されてます。
Custom Elements: 独自のHTML要素（例: <my-button>）を定義するAPI
Shadow DOM: コンポーネント内部のDOMツリーとスタイルを、外部から隔離（カプセル化）する技術
HTML Templates: 再利用可能なマークアップの断片を保持するための<template>要素と<slot>要素
この中でも、Tailwind CSSとの相性の悪さに直結するのがShadow DOMの存在です。
Shadow DOMを要素にアタッチすると、その要素はShadow Hostとなり、内部に隠されたDOMツリー（Shadow Tree）を持ちます。Shadow Tree内の要素に対するスタイルは、原則としてShadow Treeの外部（メインドキュメントや親のShadow Tree）からは影響を受けません。逆に、Shadow Treeの外部で定義されたスタイルも、原則としてShadow Tree内部には適用されません。
これは、コンポーネントのスタイルが外部のCSSルールに汚染されたり、コンポーネント内部のスタイルが外部に漏れ出たりするのを防ぐ、強力なスタイルのカプセル化機能を提供します。これにより、異なるCSS設計手法が混在する環境でも、コンポーネントの見た目が予期せず崩れるといった心配がなくなります。
下記に併用した場合のソースコードの例を記載します。
class MyStyledComponent extends HTMLElement {
  constructor() {
    super();
    // Shadow DOMをアタッチ（openモードで外部からアクセス可能に）
    const shadowRoot = this.attachShadow({ mode: 'open' });

    // Shadow DOM内部のHTML構造
    const template = document.createElement('template');
    template.innerHTML = `
      <div class="container mx-auto p-4 bg-blue-200"> // Tailwindクラスを使用
        <p class="text-xl font-bold text-gray-800">Hello from Shadow DOM!</p> // Tailwindクラスを使用
        <button class="bg-blue-500 hover:bg-blue-700 text-white font-bold py-2 px-4 rounded">
          Click me
        </button>
      </div>
    `;
    shadowRoot.appendChild(template.content.cloneNode(true));

    // ★ ここが問題 ★ Shadow DOM内部にスタイルを適用するには...？
    // 外部のスタイルシートは原則届かない
  }
}
customElements.define('my-styled-component', MyStyledComponent);
上記の例のように、MyStyledComponent の Shadow DOM 内で <div class="container mx-auto p-4 bg-blue-200"> のようなTailwindクラスを使用しても、デフォルトではこれらのスタイルは適用されません。
 Tailwind CSSについて ユーティリティファーストとグローバルCSSTailwind CSSは、flex, pt-4, text-blue-500 といった低レベルなユーティリティクラスをHTMLに直接記述することで、高速にUIを構築するアプローチを採用しています。
ビルドプロセスにおいて、TailwindはプロジェクトのHTML、JavaScript、TypeScriptファイルなどをスキャンし、使用されているユーティリティクラスに対応するCSSルールを生成します。生成されたCSSは、通常、グローバルな単一のスタイルシートとして出力され、HTMLドキュメントの<head>などに読み込まれます。
例えば、HTMLに <div class="flex pt-4"> があれば、Tailwindは以下のようなCSSルールを生成し、グローバルスタイルシートに含めます。
/* Tailwindによって生成されるCSS（の例） */
.flex {
  display: flex;
}
.pt-4 {
  padding-top: 1rem;
}
このTailwindのスタイリングメカニズムにおける重要な点は、CSSルールがグローバルスコープで定義されるという点です。
 2つの絶望的な相性の悪さ Shadow DOMのカプセル化 vs. Tailwindのグローバルスタイルここで問題の核心部分です。
Shadow DOM は、内部の要素に外部のスタイルが適用されないようにカプセル化する
Tailwind CSS は、使用されているユーティリティクラスに対応するCSSルールをグローバルスコープに生成する
この二つは根本的に矛盾します。Tailwindがグローバルに生成した.flex { display: flex; }のようなCSSルールは、Shadow DOMの境界を越えてShadow Tree内の要素に到達しないのです。
先ほどのTypeScriptの例で、<div class="container mx-auto p-4 bg-blue-200"> にTailwindのスタイルが当たらないのは、これらのクラスに対応するCSSルールがShadow DOMの外部（メインドキュメントのグローバルスコープ）に存在し、Shadow DOMがそのルールの適用をブロックしているからです。
Tailwind CSS v4について補足: Tailwind CSS v4では、新しいエンジンによるパフォーマンス向上などが謳われていますが、基本的なスタイリングのメカニズム（プロジェクトファイルをスキャンしてユーティリティクラスに対応するCSSをグローバルに生成する）という点では変わりません。したがって、v4を使用してもShadow DOMとの相性の悪さは解消されません。
 どうにかできんのか？（解決策はあるのか？）この問題を解決するために、色々調べていると、この衝突の回避策はあるにはあるが、どれもWeb ComponentsやTailwind CSSのメリットを損なう、あるいは実装コストが非常に高いものになり、根本的な解決策は見つかりませんでした。苦し紛れなものですが回避策をいくつか紹介します。
 ビルドしたTailwindのCSSをShadow DOM内にコピー＆ペーストする各Web ComponentのShadow DOM内に、そのコンポーネントで使用しているTailwindクラスに対応するCSSルールを手動、あるいはビルドツールで抽出して<style>タグとして埋め込む方法です。
デメリット:
非常に手間がかかり、メンテナンス性が低い
コンポーネントごとに重複したCSSを持つことになり、ファイルサイズが増大する
TailwindのJITコンパイル（使っているクラスだけを生成する）のメリットが活かせない
Tailwindの運用ワークフロー（設定ファイル、プラグインなど）と乖離する
 Shadow DOMを使用しないWeb ComponentsでShadow DOMを使わず、Light DOMに要素を配置する方法です。この場合、要素はメインドキュメントのDOMツリーの一部と見なされるため、グローバルなTailwindスタイルが適用されます。
デメリット:
Web Componentsの最大のメリットである「スタイルのカプセル化」が失われ、外部のCSSがコンポーネントに影響を与えたり、コンポーネントのスタイルが外部に漏れ出たりする可能性が生じてコンポーネントの独立性が損なわれる
これらのアプローチを見てもわかるように、Shadow DOMによる強力なカプセル化と、グローバルスタイルシートに依存するTailwind CSSは、根本的に思想が異なるため、無理に併用しようとするとどちらかの技術のメリットを大きく損なうことになります。
 結論：Web ComponentsとTailwind CSSは併用するべきではないこれまで見てきたように、Web Components（特にShadow DOMを利用する場合）とTailwind CSSの併用は、両者のメリットを打ち消し合ってしまうため、基本的には避けるべきです。
その理由は、2つの技術が持つスタイリングの根本的な思想・仕組みが衝突するからです。
Web Components (Shadow DOM) は、コンポーネントのスタイルを外部から完全に**隔離（カプセル化）**することを目的としている
一方、Tailwind CSS は、ユーティリティクラスに対応するCSSをグローバルなスタイルシートとして生成し、ページ全体に適用することを前提としている
このため、Tailwindが生成した便利なユーティリティクラスのスタイルは、Shadow DOMの強固な壁を越えることができず、コンポーネント内部には適用されません。
回避策は存在するものの、いずれもコンポーネントの独立性を犠牲にしたり、開発の複雑さを増大させたりと、本末転倒な結果を招きがちです。それぞれの技術の長所を最大限に活かすためには、併用しないという選択が賢明と言えるでしょう。
今回の記事が、Web ComponentsとTailwind CSSの併用を検討されている方の参考になれば幸いです。