CSSの「nth-child」を使いこなす:現場で恥をかかないためのストライプ運用の極意
フロントエンドの現場に長くいると、「CSSなんて結局は見た目を整えるだけのツールだろう」なんて軽んじる若手を見かけることがある。だが、CSSは「ブラウザという巨大なエンジンに対する、極めて宣言的な命令書」だ。特に構造的疑似クラス、その中でも `:nth-child(odd/even)` は、使い方を一つ間違えるだけで、パフォーマンスの悪化や保守性皆無のスパゲッティコードを招く地雷になり得る。
今日は、中級者として一歩先へ進むために、この古典的かつ強力なセレクタの「裏側」と、現場で本当に使えるベストプラクティスについて深掘りしていこう。
—
1. ブラウザは「何」を見ているのか?
まず、 `:nth-child` の挙動を正しく理解しよう。多くのエンジニアが「親要素の中にあるn番目の要素」と覚えているが、ブラウザの処理系視点で見ると少し解像度が変わる。
ブラウザはDOMツリーを走査する際、その要素の「兄弟要素(siblings)のインデックス」を計算し、引数に渡された式(an+b)と照合している。ここで重要なのは、「型(タグ名)は無視される」という点だ。
例えば、`div > p:nth-child(even)` と書いた場合、ブラウザは「divの中の偶数番目の要素が、たまたまpタグであるか」を判定する。もし1番目に `h1` があれば、2番目の `p` は「偶数番目」とみなされる。この「タグの種類を問わずにインデックスを数える」という仕様こそが、初心者や中級者がハマる最初の罠だ。
2. 実務で「これだけは知っておけ」という鉄板コード
テーブルのストライプやリストの交互色分けは、デザインシステムの基本だ。しかし、ただ `odd` を指定するだけでは、要素が動的に増減する現代のWebアプリでは脆すぎる。
以下は、コンポーネント指向の開発環境でもそのまま使える、堅牢なストライプ表示の実装例だ。
/
- 堅牢なストライプ表示の実装例
- 冗長なクラス付与を避け、CSSのみで完結させる
/
.list-container {
/ リセット系は親に持たせる /
list-style: none;
padding: 0;
}
.list-item {
padding: 16px;
background-color: #ffffff; / デフォルトの背景色 /
transition: background-color 0.2s ease;
}
/ 奇数行に色を付ける(1, 3, 5…) /
.list-item:nth-child(odd) {
background-color: #f8f9fa;
}
/
- 応用:ホバー時との競合を避けるために詳細度を意識する
- nth-childはクラス指定と同じ詳細度を持つので、
- 順序には十分注意が必要。
/
.list-item:hover {
background-color: #e9ecef;
}
3. なぜ `odd/even` だけで満足してはいけないのか?
実務の現場では、UIは常に変化する。「最初の3つだけ色を変えたい」「途中で特定の要素を非表示にした」といった要件が必ず飛んでくる。
ここで `:nth-child` の真価は、`n` を使った数式指定にある。
- `:nth-child(3n+1)` : 1, 4, 7… と、3つおきにスタイルを適用する。グリッドレイアウトで「3列の列ごとにスタイルを変えたい」ときに必須の知識だ。
- `:nth-child(n+4)` : 4番目以降すべてを選択する。例えば「リストが4件以上ある時だけ、広告要素を表示する」といった制御に使える。
また、最新の `:has()` セレクタと組み合わせると、表現の幅は爆発的に広がる。
/
- 応用テクニック:
- 5件以上のアイテムがある場合のみ、奇数行の背景色を強調する
/
.list-container:has(.list-item:nth-child(5)) .list-item:nth-child(odd) {
border-left: 4px solid #007bff;
}
4. 最後に:CSSアーキテクトからのアドバイス
実務でCSSを書く際、最も避けるべきは「意味のないインデックス依存」だ。もし、特定の行に必ずスタイルを当てたいのであれば、CSSの疑似クラスに頼るのではなく、クラス名(例: `.is-highlighted`)を付与する方が保守性は遥かに高い。
`:nth-child` は、「構造的に同じ性質を持つ要素群」に対して使うのが大原則だ。
- リストやテーブルなどの繰り返し要素: `nth-child` の出番。
- 意味を持つ個別のUIパーツ: 明示的なクラス名で管理する。
この境界線を常に意識してほしい。CSSは魔法ではない。ブラウザが解釈しやすい論理的な設計こそが、数年後の自分やチームを助けることになる。
さあ、エディタを開いて、君の書いているコードが本当に「構造的」に正しいかどうか、もう一度見直してみてくれ。そこにはきっと、改善の余地があるはずだ。

コメント