z-index bepaalt de voor-naar-achter stapelvolgorde van overlappende elementen — hogere waarden liggen bovenop. Maar het werkt alleen op positioned elementen, en het werkt binnen een stacking context, wat de bron van meeste z-index verwarring is.
{ : fixed; : ; }
{ : fixed; : ; }
{ : relative; : ; }
z-index wordt genegeerd op position: static (de standaard) — het element moet relative, absolute, fixed, of sticky zijn om toe te passen.
Een stacking context is een zelfstandige "laag." z-index waarden concurreren alleen binnen dezelfde context — een kind kan nooit uit de stapelniveauvan zijn ouder ontsnappen, hoe hoog de z-index ook is.
.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). */
Dit is de klassieke "mijn z-index: 9999 modal zit nog steeds achter iets" bug — de modal zit vast in een ouder die op een lager niveau is.
Veel eigenschappen creëren er stilzwijgend één, wat nakomelingen kan opvangen:
- 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 */
In de praktijk render je modals/tooltips bovenaan de DOM (React portals) zodat ze niet vast zitten in een ouder op een lager niveau.
Stacking contexts verklaren de meest verwarrende z-index bugs: een enorme z-index die nog steeds verliest omdat zijn voorouder op een lager niveau is.
Als je weet dat opacity, transform, en positioned-z-index contexten creëren — en dat kinderen daar niet uit kunnen ontsnappen — kun je overlay/dropdown ordening debuggen en je DOM (portals) correct structureren.