Re: [css3-positioning] z-index and pseudo-stacking contexts

On 24/07/2012 04:05, fantasai wrote:
> On 07/23/2012 06:52 PM, Simon Fraser wrote:
>> On Jul 23, 2012, at 5:56 PM, fantasai<fantasai.lists@inkedblade.net>
>> wrote:

>>> 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?

Yes, quite possibly. (Note that escaping used to be the specified 
behaviour, in CSS2.  That said, I imagine the CSS21 approach was adopted 
instead because implemented needed a helping hand with optimization.)

I've wished it were possible to do this many times.  I can't exactly 
give use-cases. It's simply that in a CSS21-era complex layout involving 
a mixture of floats and abspos to create "slots", one often finds 
oneself turning some or many of the slots into stacking contexts because 
of the need to control the (intentional) overlap... and, as you say, 
just because I want to control the layering doesn't mean that I 
necessarily want to "trap" the descendent stacking contexts.

But there are various issues to consider.

Firstly, even if descendant abspos boxes weren't trapped by their 
closest ancestor stacking context, their containing block would still be 
established by the closest ancestor positioned box, and that box is 
often the *same* as the closest ancestor stacking context, thanks to 
z-index primarily working with positioned boxes.  (There seems to be 
wide agreement that this was a design error.)  So this makes the whole 
thing rather less useful, because usually the reason that I want my box 
to escape is because I want it somewhere completely different, not that 
I want it to be able to paint underneath the stacking context in which 
it participates.  In other words, it would specifically be useful to be 
able to control the containing block of abspos boxes; the corresponding 
desire to control their stacking parent accordingly is really just a 
side-effect of that.

Secondly, my guess is that most of my unspecified use cases would be 
obsoleted by the new layout models that will be available post-CSS21. (I 
simply won't be absposing and floating as much.)

>>> 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?
>>
>> But then they participate with some other stacking context? What would
>> the rules be for depth sorting things across different stacking contexts?
>
> They (all z-positioned descendants) would participate in the parent
> stacking context, just like they do when the element only forms a
> pseudo-stacking context.

Thirdly, are the use cases for bubbling up to the parent's parent strong 
than the use cases for bubbling up to some more distant stacking 
context?  If I want my box to escape, maybe I want it to escape really 
deeply.

> Anyway, the first question is, do we even need to consider this. :)

Not sure.  I mean, I think it's perfectly reasonable for an author to 
want to be able to control the stacking mechanism finely; but we're not 
over-run with people requesting this, and implementers sound like 
they're pretty wary of the idea.

>> Adding rules about things escaping from their stacking context would break this
>> basic painting algorithm, and I'm not sure how you'd implement it. I'd push
>> strongly against additional complexity in this area; the z-order tree is what
>> WebKit bases it's hardware-accelerated rendering on, and that's hard enough already,
>> what with the crazy behavior of clipping (see <http://smfr.org/misc/css/stacking/css-escher.html>).

Heh, interesting test case.  In fact, that's an argument in itself in 
favour of fantasai's proposal, right?  Why does that fixpos box have to 
belong to the overflow:scroll box?  Surely that makes your rendering 
life difficult?  I imagine it would be more performant to allow it to 
escape.

Cheers,
Anton Prowse
http://dev.moonhenge.net

Received on Sunday, 7 October 2012 10:21:10 UTC