なぜ、インライン要素に `z-index` を指定しても「無視」されるのか？
フロントエンド開発の現場で、一度はこんな経験をしたことはないだろうか。
「ボタンの上に `span` で作った装飾を重ねたい。よし、`z-index: 10` を指定して……あれ？ なんで重ならないんだ？」
CSSを書き始めた頃、誰もが一度はぶつかるこの壁。`z-index` は「重ね順を制御する魔法のプロパティ」だと教わったはずなのに、特定の状況下で急に効かなくなる。実はこれ、仕様の穴ではなく、CSSのレンダリングエンジンが積み重ねてきた「重なりの階層構造（Stacking Context）」という、ある種の哲学を理解していないことが原因だ。
今日は、中級エンジニアなら絶対に押さえておくべき「インライン要素と `z-index` の不都合な真実」について、少し深掘りして解説しよう。
—
1. `z-index` が発動する「たった一つの条件」
まず、心に刻んでほしい。`z-index` は、単に値を書けば動くわけではない。`position` プロパティが `static` 以外（`relative`, `absolute`, `fixed`, `sticky`）に設定されていること。これが大前提だ。
ブラウザのレンダリングエンジンは、デフォルト状態（`position: static`）の要素を「重なりの順序を考慮しなくて良い素朴な存在」として扱う。しかし、`position` に値を与えた瞬間、その要素は「重なりの階層構造（スタッキングコンテキスト）」の住人としてランクアップする。
つまり、`span` や `a` タグといったインライン要素に対して `z-index` を効かせたいなら、まずは `display: inline-block` や `display: block` に変換した上で、`position: relative` などを付与して「ランクアップ」させてやる必要があるんだ。
—
2. 現場で役立つ「重なり順」の制御テクニック
実務では、単に `z-index` を重ねるだけでは解決できないケースも多い。例えば、「`a` タグの一部に `strong` で強調したテキストがあり、その背後に背景グラフィックを置きたい」といった場面だ。
ここで重要なのは、「スタッキングコンテキスト」は子要素の `z-index` を親要素の範囲内に閉じ込めるという性質。外側の親が `z-index: 1` で、内側の `span` が `z-index: 100` だとしても、別の親要素の `z-index: 2` には勝てない。これは「親子関係の階層」が絶対だからだ。
以下に、実務で使える「インライン要素の重ね順を美しく制御する」ためのサンプルコードを用意した。
—
3. シニアからのアドバイス：無闇に `z-index` を使わない勇気
最後に、現場の知見を一つ。
中級エンジニアにありがちなのが、重なり順が上手くいかないと、`z-index: 9999` のような「魔法の数字」を乱用してしまうことだ。これは将来の自分やチームメンバーに対する「技術的負債」になる。
重ね順がうまくいかない時は、以下の順でチェックリストを回してほしい。
1. HTMLのソース順は適切か？（DOMの最後にある要素は、何もしなくても上に重なる）
2. スタッキングコンテキストを無駄に増やしていないか？（`opacity` や `transform` を指定した要素も実はスタッキングコンテキストを作るため、`z-index` の計算をややこしくする）
3. `z-index` を指定する必要が本当にあるか？（多くの場合、CSSの記述順やレイアウト構成を見直すだけで解決できる）
`z-index` は、あくまで「最後の手段」だ。CSSの構造を整理し、DOMの前後関係を正しく理解するだけで、画面上の重なりは驚くほど綺麗に制御できる。
「なぜ動かないのか」と悩んだ時こそ、ブラウザの描画の仕組みに立ち返るチャンスだ。この感覚を身につければ、君の書くCSSは一段上のクオリティに到達するはずだ。明日からのコーディングで、ぜひ試してみてくれ。
コメント