Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
2025年のz-index設計を考える
Search
TAK
May 13, 2025
Programming
2
700
2025年のz-index設計を考える
社内勉強会用
またしても破綻しがちな z-index の設計を考える。
TAK
May 13, 2025
Tweet
Share
Other Decks in Programming
See All in Programming
Contribute to Comunities | React Tokyo Meetup #4 LT
sasagar
0
600
バイラテラルアップサンプリング
fadis
3
400
AWS Summit Hong Kong 2025: Reinventing Programming - How AI Transforms Our Enterprise Coding Approach
dwchiang
0
130
The Implementations of Advanced LR Parser Algorithm
junk0612
3
1.4k
Flutterでllama.cppをつかってローカルLLMを試してみた
sakuraidayo
0
140
Orleans + Sekiban + SignalR でリアルタイムWeb作ってみた
tomohisa
0
240
プロフェッショナルとしての成長「問題の深掘り」が導く真のスキルアップ / issue-analysis-and-skill-up
minodriven
8
1.9k
Browser and UI #2 HTML/ARIA
ken7253
2
170
generative-ai-use-cases(GenU)の推しポイント ~2025年4月版~
hideg
1
390
ComposeでのPicture in Picture
takathemax
0
130
20250426 GDGoC 合同新歓 - GDGoC のススメ
getty708
0
110
Rubyの!メソッドをちゃんと理解する
alstrocrack
1
160
Featured
See All Featured
Side Projects
sachag
453
42k
Practical Orchestrator
shlominoach
187
11k
Helping Users Find Their Own Way: Creating Modern Search Experiences
danielanewman
29
2.6k
Building a Scalable Design System with Sketch
lauravandoore
462
33k
Six Lessons from altMBA
skipperchong
28
3.8k
The Art of Delivering Value - GDevCon NA Keynote
reverentgeek
14
1.4k
Optimising Largest Contentful Paint
csswizardry
37
3.2k
Code Review Best Practice
trishagee
67
18k
Improving Core Web Vitals using Speculation Rules API
sergeychernyshev
13
840
Cheating the UX When There Is Nothing More to Optimize - PixelPioneers
stephaniewalter
280
13k
The Cost Of JavaScript in 2023
addyosmani
49
7.8k
YesSQL, Process and Tooling at Scale
rocio
172
14k
Transcript
2025 年の z-index 設計を考える
[TL;DR] z-index の設計には色々なパターンがある z-index は CSS を(悪い意味で)簡単に終わらせる z-index に数値を直接指定するのは危険
z-index とは 01 z-index の設計を考える 02 03 まとめ [ 目次
]
01 z-index とは
[概要] z-index は要素の重なりを制御するプロパティ z-index プロパティは整数値(正の数、ゼロ、負の数)で指定することができる position が static(初期値)以外の場合、または flex, grid
アイテムの場合に機能する z-index に何も指定しない(auto)の場合、または同じ正の数、ゼロの場合は、 HTML 順に後ろに配置された要素が上に重なる z-index が負の数の同じ要素は前に配置された要素が上に重なる
戦闘力の数値が大きいやつがバトルで勝つ [z-index は戦闘力]
親要素にスタッキングコンテキストが生成されるとそのスコープ内での戦闘力となる 例えば「人間」というコンテキスト内では人間同士でバトルが始まる [スタッキングコンテキスト]
スタッキングコンテキスト内での戦闘力はあくまでコンテキスト内での戦闘力 グローバルに目を向けると人間界の中では最強でも戦闘力が平凡な熊にはバトルに勝てない [スタッキングコンテキスト]
スタッキングコンテキストは生成せずに常にグローバルで戦いたい… が、残念ながらスタッキングコンテキストは簡単に生まれてしまう 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 以外
「ホバー時に透過しようとしたら z-index がバグります! どうしたらいいですか?」 opacity の値が 1 未満の時は スタッキングコンテキストが生成されるから
基本的にはスタックコンテキストの生成ありきで z-index は管理したほうがいい
02 z-index の 設計を考える
[破綻する理由] z-index がマジックナンバーと化している プロジェクトで使われている z-index の値を把握できていない 雰囲気で z-index を指定している(このくらいの数値にしておけば大丈夫だろ→もっと 前に出なきゃいけない何かが現れる→このくらいの数値にしておけば大丈夫だろの悪循
環) 他のコンポーネントの子要素の z-index とコンフリクトする 何でもかんでも z-index を指定して、どう重なるのか影響度合いがわかりにくい z-index: 999999(終わりの始まり💀) など
[考え方] z-index を「絶対的」なものか「相対的」なものか考える 絶対的なもの → 固定配置の重ね順 (追従ヘッダーやその他 fixed や sticky
な要素) 相対的なもの → コンポーネントルートを基準とした重ね順 (Block を基準とした Element の重ね順)
絶対的な z-index の設計
絶対的な z-index は グローバル変数で管理 する setting/stack.css を作成して、そこで 管理する 10の倍数などでで管理する マジックナンバーの回避
stack.css を z-index 管理表として扱う ポイント
絶対に表面に出す必要がある要素には z-index:calc(infinity) を指定する サードパーティ製の CSS の z-index よりも前に出す必要があるモーダルやローディングなどには z-index:calc(infinity) を指定して保険をかける
Tailwind でも同様 tailwind.config.js を拡張し、z-index 用 の設定を追加する Tailwind 標準のユーティリティはマジッ クナンバーと化すので使用しない ポイント
相対的な z-index の設計
原則的に z-index は使わずに DOM の順 番で制御する 指定する必要がある場合は 1(前面) か -1(背面)
のみ使用する -1 はほぼ背景用 ポイント 相対的な z-index は なるべく使わないように 頑張る
スタックコンテキストの生成ありきで z-index は管理する Elementがコンポーネントの外側に出 ないようにして、他のコンポーネント の z-index との衝動を防ぐ ポイント コンポーネントには
isolation:isolate を指定して スタッキングコンテキストを生成しておく isolation プロパティはスタッキングコンテキストの生成するか?を定義するプロパティ 他の手段より副作用が少ないのでスタッキングコンテキストを能動的に生成する場合は isolation: isolate を使用する
「コンポーネントに margin を持たせ るな」という原則と同様に、 「コンポーネントに相対的な z-index は持たせるな」 コンポーネント間の重ね順はコンポー ネントをレイアウトする親コンポーネ ントで制御する
ポイント コンポーネントそのものに相対的な z-index は持たせない
「絶対的な z-index は 10 の倍数でグローバル変数で管理する」 「相対的な z-index は 1(前面) か
-1(背面) のみ使用する」 でも、絶対誰かが z-index: 2 とかやりだすよね…😅 👆️
【提案】 相対的な z-index も変数管理して 数値指定を禁止にしよう
[相対的なz-indexも変数で指定する] stack.css に相対的定義を追加
[Stylelint で数値の指定を縛る]
03 まとめ
z-index はスタックコンテキストありきで管理する z-index は絶対的 or 相対的なもので ジャンル分けして考える コンポーネントに 相対的な z-index
を持たせない 治安悪化防止のために z-index の数値指定をやめよう (変数しか許容しないようにしよう)