The painting order in CSS is a little odd, due to the way floats work and
the fact that for legacy reasons, regular inline content needs to paint
over the floats. It's (roughly) like this:
[canvas] ---.
[negative z-index stuff] |
[all block-like backdrops] --. |
[all floats] | -- group A |-- group B
[all inline content] --' |
[positioned stuff at auto/0] |
[positive z-index stuff] ---'
Most elements (blocks, tables and table cells, flex items) have this behavior,
where all the backgrounds are all painted first, and then their inline content
in a second layer.
Some elements elements (such as a float or an inline block), however, form
a pseudo-stacking context: they do this layering thing locally for all the
group A stuff, and that mini-stack acts like a single painting thing with
respect to the surrounding context.
So then there's z-index, which let's you specify a numbered layer in the
z-axis, placing content explicitly above or below other content. One of
the side-effects of this, however, is that it forms a stacking context.
This means it creates its own little stacking universe (group B), where
nothing inside it can escape, and then that whole thing is a stack that
acts like a single painting thing with respect to the surrounding context.
The key difference between a stacking context and a pseudo-stacking context
is that in a stacking context
1. a positioned element within the stacking context can never be behind
the background of the element forming the stacking context
2. no element outside the stacking context can come between the element
forming the stacking context and any other element inside the stacking
context,
i.e. you can't interleave positioned elements in a stacking context with
elements outside the stacking context, whereas in a pseudo-stacking context,
you can.
This has always seemed a little weird to me: wouldn't you want to be able
to control an element's z-position without trapping all its descendants
(including abspos elements) inside it's stacking level?
So I have two questions (non-rhetorical):
1. Is it desired / are there use cases for having positioned context
within a z-positioned element be able to escape the z-positioned
element's stacking context?
2. If so, how can we make that specifiable?
~fantasai