【テクニカル・上級編】 :empty 擬似クラス – CSS実践ガイド

今回は、この一見無害な `:empty` が、なぜ実務で地雷を踏み抜くのか、そしてどうすれば堅牢なUIコンポーネントに昇華できるのかを、ブラウザのレンダリングエンジンの視点から紐解いていく。

—

「空白」という名の不可視の住人

`:empty` の最大の陥穽は、「テキストノードすら許容しない」という厳格な仕様にある。

実務で遭遇する地雷はこれだ。CMSから出力されるHTMLや、テンプレートエンジン（JSX含む）のインデント。これらが挿入した「たった一つの改行文字」や「スペース」が、`:empty` の判定を無効化する。

ブラウザのレンダリングエンジンにとって、ノードが存在するか否かは計算コストに直結する。DOMツリーがわずかでも肥大化すれば、スタイル計算（Recalculate Style）の負荷は微増する。しかし、 `:empty` を使った条件分岐が、「改行があるせいで効かない」というバグを生んだ時、デバッグにかかるエンジニアの工数は、レンダリング負荷の数万倍に膨れ上がる。

パフォーマンスと競合のリアリティ

非同期でDOMを動的に生成するモダンなWebアプリにおいて、 `:empty` を多用するのは危うい。

JavaScriptでリアクティブに要素を挿入する際、ブラウザは「要素が存在する」状態を検知した瞬間に `:empty` の適用を解除する。もし `:empty` で `display: none` を設定している場合、Layout Thrashing（レイアウトの強制同期）を引き起こす可能性がある。

/ 危険な使い方の例：要素の表示・非表示を :empty に依存させる /
.widget:empty {
display: none;
}

/
JSで非同期に要素を注入した際、:empty の解除と display の変更が
レンダリングパイプラインの途中で割り込み、不要なリフローを誘発する。
特に複雑なグリッドレイアウトではこれが「ガクつき」の原因になる。
/

アーキテクトが推奨する「防衛的コーディング」

では、この気難しい `:empty` をどう使いこなすべきか。答えは「依存しすぎないこと」と「CSS変数を活用したハイブリッドな戦略」だ。

もしサーバーサイドやJS側で「空の状態」を完全に保証できないなら、`:empty` を信頼してはいけない。代わりに、データ属性（`data-`）を活用するアーキテクチャへの移行を強く推奨する。

/
推奨される戦略：
純粋な DOM の空状態ではなく、状態管理層からのフラグで制御する
/
.widget {
/ 基本的に表示はJS側の状態に依存させる /
}

.widget[data-status=”empty”] {
display: none;
}

それでもなお、CSSだけで完結させたいというのなら、CSSの `:not(:empty)` を組み合わせた「存在する場合のみ適用する」というアプローチをとるのが、最も堅牢な設計だ。

/ 子要素が存在する場合のみパディングを付与する（堅牢な設計） /
.card {
padding: 0;
transition: padding 0.2s ease;
}

.card:not(:empty) {
padding: 1.5rem; / 子要素がある時だけスペースを確保し、視覚的な崩れを防ぐ /
}

最後に：エンジニアの美学

`:empty` は強力だが、その「空っぽ」の定義はあまりに繊細だ。

フロントエンドのアーキテクトとして最も忌むべきは、「なぜか意図した通りに表示されない」という不可解なバグをコードベースに残すことだ。HTMLの改行一つで挙動が変わるようなセレクタに、重要なロジックを依存させてはいけない。

もし、プロジェクト内で `:empty` を見かけたら、その周囲に「なぜこのセレクタが安全なのか」を証明するテストコードやコメントがあるかを確認してほしい。なければ、そこは書き直すべき技術的負債の種だ。

CSSは、魔法ではない。ただの論理だ。その論理の境界線をどこに引くか。そこにこそ、真のスペシャリストの価値が宿る。