Serious question: why do stacking contexts exist? They seem to defeat the whole purpose of z-indexes, which is a global way of determining what shows up in front of what else.
I'm trying to wrap my head around them -- I guess the main takeaway is, if you don't ever want to have to deal with them, then don't ever use nested elements where both have z-indexes?
It seems to be to make pages more composable - so at the top level you can specify what order block A and B are stacked, and within A and B you can independently specify what order the blocks that make those up are stacked.
This way you can change the relative order of A and B without worrying about how those blocks are internally structured, and whether they use z-index themselves.
To enforce upper-boundary encapsulation, CSS rules declared by the document must not apply in a shadow DOM subtree, unless the apply-author-styles flag is set for this subtree. The flag signals that document CSS rules are applicable in the shadow DOM subtree.
Conversely, to enforce lower-boundary encapsulation, CSS rules declared in a shadow DOM subtree must not apply in the document tree."
A stacking context is analogous to a frame buffer object in OpenGL or a render target in Direct3D. (I'm reasonably sure this is what at least some browsers do for rendering elements with partial opacity.) The difference in opacity (generally) necessitates rendering the content in its own buffer and then rendering it into the viewport.
It's fairly prohibitive to try to correctly break up the differing Z-indexes and do the right thing when rendering, and was probably easier, with no real loss of functionality, to introduce stacking contexts.
I'm trying to wrap my head around them -- I guess the main takeaway is, if you don't ever want to have to deal with them, then don't ever use nested elements where both have z-indexes?