こんにちは。フロントエンドの現場で日々、DOMの海を泳ぎながらセレクタの最適化に命を削っているチーフアーキテクトだ。
CSSの進化において、これほどゲームチェンジャーだった機能が他にあっただろうか。そう、`:has()`擬似クラスだ。これまで「親要素を選択できない」というCSSの宿命を打破するために、私たちはJavaScriptで無理やりクラスを付与し、メモリを浪費し、レンダリングのメインスレッドをブロックしてきた。
だが、時代は変わった。`:has()`は単なる「親セレクタ」ではない。これは、DOMツリーの構造的関係性をリアクティブに監視し、宣言的にスタイルを制御するためのCSSエンジン向けの強力なクエリ言語だ。
今回は、この`:has()`を単なる小手先のテクニックとしてではなく、大規模なWebアプリケーションにおいて堅牢かつハイパフォーマンスに運用するための「実務デザインパターン」を、ブラウザの内部挙動やレンダリング負荷の観点交えて深掘りしていこう。
—
1. なぜ`:has()`は「親セレクタ」以上の存在なのか？
まず、CSSエンジンの内部挙動から話を始めよう。
従来のCSSセレクタは、右から左（Right-to-Left）へ評価される。例えば `.card .title` なら、まずすべての `.title` を探し、その祖先方向に `.card` があるかを遡る。これはパフォーマンスを担保するための古典的かつ洗練されたアルゴリズムだ。
しかし、`:has()`が登場したことで、ブラウザはDOMの「前方参照」や「双方向のツリー走査」を効率的にこなす必要に迫られた。
幸い、近年のBlink、WebKit、Geckoの各エンジンは、`:has()`の評価を高度に最適化している。とはいえ、使い方を誤ればレンダリングのボトルネックになり得るのも事実だ。
特に大規模なSPA（Single Page Application）において、ルートに近い要素（例えば `body` や `#app`）に対して広範囲な `:has()` を多用すると、DOMの変異（Mutation）のたびにスタイル計算のスコープが広がり、スタイル再計算（Recalculate Style）のコストが跳ね上がる。
これを防ぐための第一原則は、「スコープを可能な限り局所化し、兄弟要素や直近のコンテナ境界に閉じたセレクタ設計を行うこと」だ。
—
2. 実務で即効性のあるデザインパターン
ここからは、現場のコードベースで明日から使える具体的なデザインパターンを見ていこう。
パターンA: フォームのバリデーション状態に応じたコンテナ全体のスタイリング
フォームUIの実装で、入力欄（``）がエラーのときに、その親であるフィールドセットやカード全体の枠線を赤くし、エラーメッセージをフワッと表示したい要件はよくある。従来ならJSで `is-error` などのクラスをトグルしていたはずだ。
これを `:has()` でスマートに解決する。
/ フィールドグループの基本スタイル /
.form-field-group {
border: 1px solid var(–color-border-base);
padding: 1.25rem;
border-radius: 8px;
transition: border-color 0.2s ease, background-color 0.2s ease;
}
/
内部のインプットにフォーカスがある、またはHTML5バリデーションで無効かつdirtyな状態のとき、
コンテナ自体のスタイルをリアクティブに変更する
/
.form-field-group:has(input:focus) {
border-color: var(–color-primary);
box-shadow: 0 0 0 3px rgba(0, 123, 255, 0.15);
}
/ ユーザーが入力中でエラー状態の制御 /
.form-field-group:has(input:user-invalid) {
border-color: var(–color-danger);
background-color: var(–color-danger-subtle);
}
/ エラー時のメッセージ表示制御（通常時は隠しておき、親がエラーの時だけ出す） /
.form-field-group .error-message {
max-height: 0;
opacity: 0;
overflow: hidden;
transition: max-height 0.3s ease, opacity 0.2s ease;
color: var(–color-danger-text);
font-size: 0.875rem;
margin-top: 0.5rem;
}
.form-field-group:has(input:user-invalid) .error-message {
max-height: 3rem;
opacity: 1;
}
このアプローチの美しいところは、JSのイベントリスナーを一切汚染せずに、ブラウザのネイティブなバリデーション状態と完全に同期する点だ。メモリリークの心配も、状態管理のバグもない。
—
パターンB: 画像の有無によるグリッドレイアウトの動的適応
CMSやユーザー投稿型のプラットフォームで頭を悩ませるのが、「画像があるカードとなし混在するレイアウト」だ。デザイナーは「画像がある場合は2カラム、画像がない場合はテキスト主体なので1カラム（または全幅）」というリッチなレイアウトを要求してくる。
これを `:has()` なしでやろうとすると、テンプレート側でサーバーサイドあるいはJSで条件分岐し、`.card–with-image` のようなModifierクラスを付与する必要があった。
しかし、`:has()` があれば、DOM構造は完全に同一のままでCSSだけで制御できる。
/ カードのベースレイアウト（デフォルトはテキストのみを想定した1カラム構成） /
.content-card {
display: grid;
grid-template-columns: 1fr;
gap: 1rem;
padding: 1.5rem;
background: #fff;
border-radius: 12px;
}
/
もしカード内に画像コンテナ（.card-media）が存在する場合のみ、
グリッドテンプレートを動的に2カラムへと組み替える
/
.content-card:has(.card-media) {
grid-template-columns: 240px 1fr;
}
/ メディアが存在しない場合のタイポグラフィ調整などもここで完結 /
.content-card:not(:has(.card-media)) .card-title {
font-size: 1.5rem; / 画像がないときはタイトルを大きくする等の微調整 /
}
@media (max-width: 768px) {
/ モバイルビューでは画像有無に関わらず1カラムにフォールバック /
.content-card:has(.card-media) {
grid-template-columns: 1fr;
}
}
テンプレートの複雑性を極限まで下げ、デザインの関心を完全にCSS層に閉じ込める。これぞモダンフロントエンドアーキテクチャの真骨頂だ。
—
3. パフォーマンスの罠と回避策：知られざる「重い」書き方
さて、ここからがチーフアーキテクトとしての本領発揮だ。`:has()` は強力だが、使い方を誤るとレンダリングのパフォーマンスを深刻に劣化させる。
1. グローバルな監視コスト
例えば、以下のようなセレクタを書いたとしよう。
/ 絶対にやってはいけないアンチパターン /
body:has(.is-modal-open) {
overflow: hidden;
}
一見、モーダルが開いているときにスクロールを固定するスマートな方法に見える。しかし、ブラウザは「DOMツリーの頂点（`body`）」から `.is-modal-open` の存在を常に監視しなければならなくなる。DOMの規模が大きくなればなるほど、あらゆるDOM変更（Mutation）のたびにエンジンは全ツリーの再評価コストを支払うことになる。
【回避策】
状態管理は、影響を受ける最小限のコンテナ、あるいはダイアログ自体の近傍で完結させるべきだ。
/ モーダルが開いているときのダイアログ自身の状態変化として記述する /
dialog[open] {
animation: modal-fade-in 0.3s cubic-bezier(0.16, 1, 0.3, 1);
}
どうしても `body` 側に影響を与えたい場合は、CSSだけで頑張らず、素直にJSで `document.body.classList.add(‘is-locked’)` を付与するほうが、ブラウザの描画パイプラインにとっては遥かに優しかったりする。すべてのロジックを無理にCSSに寄せることが、必ずしも正解とは限らない。この見極めこそがプロのアーキテクトだ。
2. `:not()` との組み合わせによる計算量の爆発
`:has()` の中に `:not()` をネストさせたり、複雑な論理結合（AND/OR）を行うと、セレクタのマッチング判定が指数関数的に重くなるケースがある。
/ 危険な香り漂う複雑なクエリ /
.card:has(:not(img):not(video)):has(.tag-special) {
/ … /
}
複雑な条件が必要な場合は、CSS変数を介したハイブリッドなアプローチや、セレクタをシンプルに分割することを強く推奨する。
—
4. レガシーブラウザとの共存戦略（フォールバック）
忘れてはならないのが、エンタープライズ領域や特定のターゲット層においては、まだ `:has()` を完全にサポートしていない環境（あるいは古いWebビューなど）が存在する現実だ。
実務においては、@supports を用いたプログレッシブ・エンハンスメント（段階的拡張）を徹底する。
/ ベーススタイル（すべてのブラウザで安全に動くフォールバック） /
.form-field-group {
border: 1px solid var(–color-border-base);
}
.form-field-group .error-message {
display: none; / 古いブラウザでは単純に隠す /
}
/ ブラウザが :has() をサポートしている場合のみ、高度なスタイルとアニメーションを適用 /
@supports selector(:has()) {
.form-field-group {
transition: border-color 0.2s ease;
}
.form-field-group .error-message {
display: block;
max-height: 0;
opacity: 0;
overflow: hidden;
transition: max-height 0.3s ease, opacity 0.2s ease;
}
.form-field-group:has(input:user-invalid) {
border-color: var(–color-danger);
}
.form-field-group:has(input:user-invalid) .error-message {
max-height: 3rem;
opacity: 1;
}
}
この防衛的なコード書き方こそが、プロダクトの品質を担保し、予期せぬレイアウト崩壊からユーザーを守る盾となる。
—
5. まとめ
`:has()` 擬似クラスは、CSSを「静的な装飾言語」から「動的な構造クエリ言語」へと変貌させた偉大な機能だ。
しかし、その強大なパワーゆえに、DOMの構造やブラウザのレンダリングメカニズムを理解せずに乱用すれば、パフォーマンスの劣化というしっぺ返しを喰らうことになる。
- スコープを最小限に絞り、グローバルなルート要素での多用は避ける。
- JSの役割とCSSの役割の境界線を正しく見極める。
- @supportsを活用した堅牢なプログレッシブ・エンハンスメントを組む。
この哲学を胸に刻み、美しく、かつパフォーマンスに妥協のない、最高峰のフロントエンドアーキテクチャを構築してほしい。君たちのコードベースが、洗練されたCSSの知見で満たされることを期待している。
コメント