z-index kontroluje porządek stos od przodu do tyłu nakładających się elementów — wyższe wartości leżą na szczycie. Ale działa tylko na elementach positioned i działa w ramach kontekstu stosu, która jest źródłem większości zamieszania z z-index.
{ : fixed; : ; }
{ : fixed; : ; }
{ : relative; : ; }
z-index jest ignorowany na position: static (domyślnie) — element musi być relative, absolute, fixed lub sticky, aby się zastosować.
Kontekst stosu to samowystarczalna "warstwa". Wartości z-index konkurują tylko w ramach tego samego kontekstu — dziecko nigdy nie może uciec z poziomu stosu rodzica, bez względu na to, jak wysoki jest z-index.
.parent-a { position: relative; z-index: 1; }
.parent-b { position: relative; z-index: 2; }
.child-of-a { position: absolute; z-index: 9999; }
/* ❌ child-of-a STILL renders below everything in parent-b, */
/* because parent-a (z-index 1) is entirely below parent-b (z-index 2). */
To jest klasyczny błąd "mój z-index: 9999 modal jest nadal za czymś" — modal jest uwięziony w rodzicu, który jest na niższej warstwie.
Wiele właściwości potajemnie tworzy jeden, co może uwięzić potomków:
- position + z-index (other than auto)
- opacity less than 1
- transform, filter, will-change
- isolation: isolate
- a flex/grid item with z-index
/* render the modal at the document root (outside trapping parents) — "portal" */
.isolated { isolation: isolate; } /* deliberately create a context where you want one */
W praktyce renderuj modale/tooltipsy na szczycie DOM (React portals), aby nie były uwięzione w rodzicu na niższej warstwie.
Konteksty stosu wyjaśniają najbardniejsze błędy z-index: ogromny z-index, który nadal przegrywa, ponieważ jego przodek jest na niższej warstwie.
Znajomość tego, że opacity, transform i positioned-z-index tworzą konteksty — i że dzieci nie mogą ich opuścić — pozwala ci debugować kolejność overlay/dropdown i poprawnie strukturować DOM (portals).