- From: fantasai <fantasai.lists@inkedblade.net>
- Date: Mon, 23 Jul 2012 20:56:41 -0400
- To: "www-style@w3.org" <www-style@w3.org>
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
Received on Tuesday, 24 July 2012 00:57:10 UTC