2025年のz-index設計を考える

社内勉強会用

またしても破綻しがちな z-index の設計を考える。

---

【質問への解答】

Q. Sassのmapでの管理はどうですか？

使用しなくて良いと思います。
理由としては、z-index を map で定義したとしても @each するわけでもなく旨味が無いこと。
`z-index: map.get(global.$stack, header)` のように定義するより変数をベタ書きしたほうが記述量は少ないこと。
変に map 化するよりベタでハイフンつなぎの変数名になってたほうが補完が効くのでありがたいからです。

個人的には @property で継承を false にしたカスタムプロパティの使用を推奨します。
デベロッパーツールでデバッグがやりやすいのに加えて、不意に上書きされたとしても継承を無効にしてダメージを抑えられるためです。
CSS標準の機能なため、プリプロセッサやフレームワークに依存せず移管しやすいのも見逃せないメリットです。

---

Q. 絶対的な z-index はコンポーネントに持たせるべき？

個人的には絶対的な z-index も Pages コンポーネントの Element で管理したほうがいいと思います。

例外を除き、絶対的な z-index は Pages コンポーネントの相対 z-index と捉えることができるため。
加えて、Pages コンポーネントの Element で一元管理したほうが定義が分散しなくてわかりやすいからです。

ただし、従来のCSS設計では絶対的な z-index は Layout レイヤーの持ち物であり、これらは直接呼び出されるのが慣習としてあるのでそれに合わせるかによります。

コンポーネント自体に持たせる例外としてはモーダルウィンドウが挙げられます。

モーダルウィンドウは画面全体をジャックし、かつ背面が inert される関係上、親の Pages とは独立した一つの「ページ」として捉えることができます。
そのため、基本的にモーダルウィンドウは Pages コンポーネントとして扱い、z-index の指定を許容するのが良いでしょう。

※dialog 要素で showModal() する場合はトップレイヤーに配置されるため z-index の指定は不要です。

Transcript

1. 2025 年の z-index‌ 設計を考える‌
2. [TL;DR] z-index の設計には色々なパターンがある z-index は CSS を（悪い意味で）簡単に終わらせる z-index に数値を直接指定するのは危険
3. z-index とは 01 z-index の設計を考える 02 03 まとめ [ 目次 ]
4. 01 z-index とは
5. [概要] z-index は要素の重なりを制御するプロパティ z-index プロパティは整数値（正の数、ゼロ、負の数）で指定することができる position が static（初期値）以外の場合、または flex, grid アイテムの場合に機能する z-index に何も指定しない（auto）の場合、または同じ正の数、ゼロの場合は、 HTML 順に後ろに配置された要素が上に重なる z-index が負の数の同じ要素は前に配置された要素が上に重なる
6. 戦闘力の数値が大きいやつがバトルで勝つ [z-index は戦闘力]
7. 親要素にスタッキングコンテキストが生成されるとそのスコープ内での戦闘力となる 例えば「人間」というコンテキスト内では人間同士でバトルが始まる [スタッキングコンテキスト]
8. スタッキングコンテキスト内での戦闘力はあくまでコンテキスト内での戦闘力 グローバルに目を向けると人間界の中では最強でも戦闘力が平凡な熊にはバトルに勝てない [スタッキングコンテキスト]
9. スタッキングコンテキストは生成せずに常にグローバルで戦いたい… が、残念ながらスタッキングコンテキストは簡単に生まれてしまう position の値が absolute あるいは relative で、かつ z-index の値が auto 以外 position の値が fixed あるいは sticky display: flex あるいは display: grid の子要素で、かつ z-index の値が auto 以外 opacity の値が 1 未満 mix-blend-mode の値が normal 以外 transform、filter、perspective、clip-path、mask の値が none 以外
10. 「ホバー時に透過しようとしたら z-index がバグります！ どうしたらいいですか？」 opacity の値が 1 未満の時は スタッキングコンテキストが生成されるから
11. 基本的にはスタックコンテキストの生成ありきで z-index は管理したほうがいい
12. 02 z-index の 設計を考える
13. [破綻する理由] z-index がマジックナンバーと化している プロジェクトで使われている z-index の値を把握できていない 雰囲気で z-index を指定している（このくらいの数値にしておけば大丈夫だろ→もっと 前に出なきゃいけない何かが現れる→このくらいの数値にしておけば大丈夫だろの悪循 環） 他のコンポーネントの子要素の z-index とコンフリクトする 何でもかんでも z-index を指定して、どう重なるのか影響度合いがわかりにくい z-index: 999999（終わりの始まり💀） 　 など
14. [考え方] z-index を「絶対的」なものか「相対的」なものか考える 絶対的なもの → 固定配置の重ね順 （追従ヘッダーやその他 fixed や sticky な要素） 相対的なもの → コンポーネントルートを基準とした重ね順 （Block を基準とした Element の重ね順）
15. 絶対的な z-index の設計
16. 絶対的な z-index は グローバル変数で管理 する setting/stack.css を作成して、そこで 管理する 10の倍数などでで管理する マジックナンバーの回避 stack.css を z-index 管理表として扱う ポイント
17. 絶対に表面に出す必要がある要素には z-index:calc(infinity) を指定する サードパーティ製の CSS の z-index よりも前に出す必要があるモーダルやローディングなどには z-index:calc(infinity) を指定して保険をかける
18. Tailwind でも同様 tailwind.config.js を拡張し、z-index 用 の設定を追加する Tailwind 標準のユーティリティはマジッ クナンバーと化すので使用しない ポイント
19. 相対的な z-index の設計
20. 原則的に z-index は使わずに DOM の順 番で制御する 指定する必要がある場合は 1(前面) か -1(背面) のみ使用する -1 はほぼ背景用 ポイント 相対的な z-index は なるべく使わないように 頑張る
21. スタックコンテキストの生成ありきで z-index は管理する Elementがコンポーネントの外側に出 ないようにして、他のコンポーネント の z-index との衝動を防ぐ ポイント コンポーネントには isolation:isolate を指定して スタッキングコンテキストを生成しておく isolation プロパティはスタッキングコンテキストの生成するか？を定義するプロパティ 他の手段より副作用が少ないのでスタッキングコンテキストを能動的に生成する場合は isolation: isolate を使用する
22. 「コンポーネントに margin を持たせ るな」という原則と同様に、 「コンポーネントに相対的な z-index は持たせるな」 コンポーネント間の重ね順はコンポー ネントをレイアウトする親コンポーネ ントで制御する ポイント コンポーネントそのものに相対的な z-index は持たせない
23. 「絶対的な z-index は 10 の倍数でグローバル変数で管理する」 「相対的な z-index は 1(前面) か -1(背面) のみ使用する」 でも、絶対誰かが z-index: 2 とかやりだすよね…😅 👆️
24. 【提案】 相対的な z-index も変数管理して 数値指定を禁止にしよう
25. [相対的なz-indexも変数で指定する] stack.css に相対的定義を追加
26. [Stylelint で数値の指定を縛る]
27. [Tailwindの場合]
28. 03 まとめ
29. z-index はスタックコンテキストありきで管理する z-index は絶対的 or 相対的なもので ジャンル分けして考える コンポーネントに 相対的な z-index を持たせない 治安悪化防止のために z-index の数値指定をやめよう （変数しか許容しないようにしよう）