Z-index: 99999 failing to put an element on top is not a bug. It is stacking contexts working exactly as specified. When a CSS property like opacity, transform, filter, or position with a non-auto z-index is applied to an element, the browser creates a new stacking context: a self-contained layer that groups the element and all its children. A child inside that group can never visually escape it, no matter how high its z-index is set.
The folder analogy in this piece makes the core rule concrete. Two sibling divs, folder-a with z-index: 1 and folder-b with z-index: 2, are stacked against each other first. A child inside folder-a set to z-index: 9999 still loses to a child inside folder-b set to z-index: 5, because the browser resolves parent stacking order before it ever looks at children. The article also explains why transform and opacity trigger new stacking contexts at all: it is a rendering performance decision, not a visual one. The browser isolates those elements into separate compositor layers to avoid recalculating the entire page on every animation frame. That side effect is what traps your modal.
The practical half of the article walks through specific failure scenarios, starting with a fixed-position modal overlay set correctly in isolation but buried because its parent lives inside another stacking context. The full MDN list of stacking-context-creating properties is linked, and the piece is worth reading in full because the fix is never universal. How you unstack an element depends entirely on where in the tree the rogue stacking context was created, and this article shows you how to find it.
[READ ORIGINAL →]