CSSの「子結合子（>）」を制する者は、カスケードの混沌を制す
現場でコードを読んでいると、CSSのセレクタが際限なく肥大化して、どこで何が上書きされているのか分からなくなる……そんな経験はないだろうか？
「とにかく動けばいい」と適当なセレクタを重ね続けた結果、数ヶ月後の自分が修正に頭を抱える。これはフロントエンド開発におけるあるあるだが、この「負の遺産」を断ち切るための最も強力かつシンプルな武器が、今回深掘りする子結合子（`>`）だ。
単なる「直下を選択する記号」として片付けるのはもったいない。これこそが、CSSの保守性を担保する「防波堤」なのだ。
—
1. なぜ「孫」まで巻き込んではいけないのか
CSSの基本である子孫結合子（スペース）は、便利だが強力すぎる。
/ これだと、孫、ひ孫まで全ての影響を受ける /
.card .title {
color: red;
}
例えば、カードコンポーネントの中に別のネストされた要素が存在する場合、意図せずスタイルが漏れ出す。いわゆる「スタイルの汚染」だ。これに気づかず実装を進めると、後から「なぜか孫要素の色が変わらない」という謎のバグと戦う羽目になる。
ここで `>` を使ってみよう。
/ 直下の .title だけに限定する /
.card > .title {
color: red;
}
この一行だけで、「このカードの直下にあるタイトル以外には、絶対に影響を与えない」という強い意思表示ができる。これが設計の明瞭さを生む。
2. ブラウザの裏側で何が起きているか
中級エンジニアなら、ブラウザがCSSをどう解釈しているか、少しだけ覗いておこう。
ブラウザのレンダリングエンジンは、セレクタを「右から左」に読み込む。`div > .item` というセレクタがあれば、まず `.item` クラスを持つ要素をすべて探し出し、その親が `div` であるかどうかを判定する。
もし、深くネストされた子孫セレクタを多用すると、ブラウザは親要素の階層を延々と遡って確認しなければならない。一方で、子結合子は「親が直近の要素か？」を確認するだけなので、計算コストが非常に低い。つまり、子結合子を使うことは、パフォーマンス的にも合理的なのだ。
3. 実務で即戦力になる「境界線」の作り方
実際に現場でよくある「リストのセパレーター」を例に、具体的なコードを見てみよう。
ここで「liの間にボーダーを引きたい」という要件があったとする。
/ 悪い例：これだとサブメニューのliにもボーダーが入ってしまう /
.nav-list li {
border-top: 1px solid #ccc;
}
/ 良い例：直下のみを対象にする /
.nav-list > li {
border-top: 1px solid #ccc;
}
/ 最初の要素にはボーダーが不要な場合も、子結合子で綺麗に書ける /
.nav-list > li:first-child {
border-top: none;
}
このように、子結合子を使うことで「コンポーネントの責務」をその階層に限定できる。これにより、`sub-list` のようなネストされた要素に余計なCSSを書く必要がなくなり、結果としてコードが驚くほどスッキリする。
4. チーフアーキテクトからのアドバイス
実務で意識してほしいのは、「セレクタの長さを競うな、境界線を定義せよ」ということだ。
- コンポーネントのルート（親）には必ず一意のクラスを振る
- その直下にある重要な構造的要素には `>` を使って紐付ける
- 深すぎるネスト（3階層以上）が必要な場合は、CSSの設計（クラス命名など）を見直すサイン
`>` を使うことは、単なる記法の選択ではない。「このCSSはこの範囲までしか関与しません」という、未来の自分やチームメイトに対する強固な契約書なんだ。
明日からの実装で、まずは「スペース」を打つ前に「本当に孫まで選択する必要があるか？」と一瞬だけ立ち止まってみてほしい。その小さな迷いが、あなたのCSSを世界レベルのアーキテクチャへと押し上げるはずだ。
さあ、エディタを開いて、不必要なセレクタをどんどん切り離していこう。コードの切れ味が変わるのを実感できるはずだ。
コメント