【テクニカル・上級編】 has関係疑似クラス – CSS実践ガイド

CSS界の歴史的パラダイムシフトであり、長年の悲願であった「親セレクタ」こと `:has()` 疑似クラス。これが標準仕様として各ブラウザに実装されたとき、多くのフロントエンド・エンジニアが歓喜の声を上げました。「もうJavaScriptでDOMを監視してクラスを付け替える必要はないんだ」と。

しかし、チーフアーキテクトである私から一言言わせてください。
「力には、相応の代償が伴う」 ということを忘れてはいけません。

`:has()` は強力すぎます。そのため、内部挙動やブラウザのレンダリングパイプラインを理解せずに安易にプロダクション環境へ投入すると、メモリ効率の悪化、レイアウトスラッシング、そして予測不可能な再描画コストの増大という名の「技術的負債」を即座に生み出します。

今回は、上級エンジニアのあなたに向けて、`:has()` の内部挙動と、大規模Webアプリケーションで破綻しないための堅牢なアーキテクチャ設計について深く掘り下げていきましょう。

—

1. なぜ `:has()` は危険なのか？ ブラウザエンジンの内部挙動

これまでのCSSセレクタは、基本的に「上から下へ（あるいは右から左へと効率的にマッチングさせる）」という、DOMツリーの方向性に沿った高速な走査が可能でした。例えば `.card h2` であれば、`.card` を見つけてからその中を覗きに行くため、計算量は比較的安定しています。

しかし、`:has()` は「子や兄弟の存在によって、親（あるいは先行する兄弟）のスタイルを変える」という、DOMツリーの逆流（Parent/Ancestor Selection）を引き起こします。

ライフサイクルと「スタイル再計算（Style Recalculation）」のコスト

Blink（Chromium）やWebKitなどのモダンブラウザエンジンにおいて、DOMの一部が変化すると、スタイル再計算のプロセスが走ります。
`:has()` が絡むと、ブラウザは「影響を受ける可能性のあるすべての祖先要素」を逆方向に辿り、ツリー全体の依存関係グラフ（Dependency Graph）を構築し直す必要があります。

特に、深さのあるコンポーネントツリーのルート付近で広範囲な `:has()` を多用すると、わずかなDOMの変更（例えば、フォームの1つのインプットが `:focus` になった瞬間など）が、ドキュメント全体を巻き込んだ重いスタイル再計算を引き起こす「スタイルの雪崩」を誘発します。これが、レンダリングフレームレート（60fps）を容易に殺す原因となります。

—

2. 実務で直面するパフォーマンスの罠とアンチパターン

よくある事故の筆頭が、「グローバルな状態検知」としての濫用です。実務の現場でやりがちな、しかし絶対に避けるべきアンチパターンを見てみましょう。

アンチパターン：ドキュメントルート付近での広範囲 `:has()`

/ 【悪夢】ページ内のどこかのフォームにエラーがあるだけで、body全体が監視対象になる /
body:has(:invalid) {
–global-form-status: “error”;
}

/ 【地獄】何重にもネストされたコンポーネントの深部でこれをやると、依存関係グラフが爆発する /
.app-container:has(.card:hover) {
box-shadow: 0 20px 25px -5px rgba(0, 0, 0, 0.1);
}

このコードの何が問題か分かりますか？
ブラウザは、ページ上のあらゆる要素が変化するたびに、「今、`.app-container` の子孫に `.card:hover` が存在するか？」を再評価し続けなければなりません。コンポーネントが肥大化すればするほど、このクエリの計算コストは線形（あるいはそれ以上）に跳ね上がります。

—

3. 堅牢なアーキテクチャのための最適化戦略

では、私たちはこの強力な武器を諦めるべきなのでしょうか？
いいえ、アーキテクチャの設計思想をアプローチに落とし込めば、極めて安全かつ高速に `:has()` を使いこなすことができます。

戦略 A: スコープの極小化（コンポーネント単位の封じ込め）

`:has()` を適用する対象は、常に「最小限の局所的なコンポーネント」に限定すべきです。BEMやCSS Modulesなどのスコープ化された設計思想と組み合わせることで、依存関係グラフの伝播範囲を最小限に抑え込みます。

以下は、フォームのバリデーション状態を極小スコープで制御する、モダンかつ堅牢な実装例です。

/

• 【最適解】コンポーネントのルート（.field-group）自身を起点にし、
• その内部の局所的な状態変化のみをハンドリングする。
• これにより、ブラウザのスタイル再計算のスコープがこのDOMノード周辺に限定される。

/
.field-group {
display: flex;
flex-direction: column;
gap: 0.25rem;
transition: border-color 0.2s ease;
}

/ 通常時はエラーメッセージを不可視化（レイアウトシフトを防ぐため visibility も併用） /
.field-group .field-error-message {
opacity: 0;
visibility: hidden;
max-height: 0;
font-size: 0.875rem;
color: var(–color-danger, #ef4444);
transition: opacity 0.2s ease, max-height 0.2s ease;
}

/

• 核心：inputがフォーカスされており、かつ「無効（invalid）」な状態である場合のみ、
• 親である .field-group のスタイルと、子孫のエラーメッセージの表示状態を制御する。
• ツリーの逆流コストは、このコンポーネント内部（数ノードの深さ）に完全にカプセル化される。

/
.field-group:has(input:focus:invalid) {
–current-border-color: var(–color-danger, #ef4444);
}

.field-group:has(input:focus:invalid) .field-error-message {
opacity: 1;
visibility: visible;
max-height: 2rem;
}

.field-group input {
border: 1px solid var(–current-border-color, var(–color-gray, #cbd5e1));
border-radius: 0.375rem;
padding: 0.5rem;
outline: none;
}

戦略 B: 動的なレイアウト切り替え（Container Queries との共生）

リッチなUIコンポーネントを作る際、グリッドのレイアウトを子要素の数に応じて動的に変えたい要件はよくあります。かつてはJavaScriptで子要素の数（`children.length`）を数えてクラスを付与していましたが、`:has()` なら純粋なCSSで完結します。

ここでも、メディアクエリやグローバルではなく、コンポーネント境界内で処理します。

.card-grid {
display: grid;
grid-template-columns: 1fr;
gap: 1rem;
}

/ 子要素に特定のクラスを持つカードが「2枚」存在する場合のレイアウト変更 /
.card-grid:has(.card:nth-child(2):last-child) {
grid-template-columns: repeat(2, 1fr);
}

/ 子要素が3枚以上の場合のレイアウト変更 /
.card-grid:has(.card:nth-child(3)) {
grid-template-columns: repeat(3, 1fr);
}

このアプローチにより、JSのResizeObserverやMutationObserverを排除し、メインスレッドのJS実行時間を削り取ることができます。描画のパフォーマンスは、最終的にブラウザのC++層（レンダリングエンジン）に最適化されるため、JS起因のボトルネックを確実に回避できます。

—

4. チーフアーキテクトからの提言：これからのCSS設計における心構え

`:has()` 疑似クラスは、フロントエンド開発における「JSとCSSの責務の境界線」を大きく塗り替えました。これまでJavaScriptが担うべきだった「状態に応じたDOM構造の監視とスタイリングの制御」の大部分が、CSSの領域に移行しました。

しかし、忘れないでください。「CSSでできるからといって、何でもかんでもCSSに書けばいい」というわけではありません。

1. スコープを意識する: グローバルな状態（`body`, `main`, `.app` など）を `:has()` の起点にしないこと。
2. 依存関係の深さに怯える: 5階層も6階層も離れた子孫の状態を親が `:has()` で監視するような設計は、コードの可読性を下げ、パフォーマンスの地雷を踏むことと同義です。
3. フォールバックとプログレッシブ・エンハンスメント: まだ古いブラウザをサポートする必要があるエンタープライズ環境では、`:has()` が使えない環境でもUXが破綻しないような設計（あるいは `@supports` の活用）を忘れないこと。

道具は使いようです。メモリ効率とレンダリングパイプラインのメカニズムに敬意を払いながら、この強力な親セレクタをあなたのアーキテクチャの武器として正しく組み込んでください。

真に堅牢で、メンテナンス性が高く、そして何より美しいWebアプリケーションは、こうした細部への徹底的なこだわりから生まれるのです。