Re: [css3-flexbox] Paint flex items atomically?

On 04/07/2012 19:27, L. David Baron wrote:
> On Thursday 2012-06-28 11:00 +0200, Morten Stenshorne wrote:
>> Should flex items be treated as if they sort of establish a new stacking
>> context (except for descendants that are positioned or create true
>> stacking contexts on their own)? I'm talking about what
>> http://www.w3.org/TR/CSS2/zindex.html has to say about inline-block,
>> inline-table and floats.
>
> I tend to think that they should be.  (And I think it's weird that
> table cells don't do this as well, but they don't.)
>
> As a brief reminder, this behavior exists to support implementing
> the requirement in http://www.w3.org/TR/CSS21/visuren.html#floats
> that:
>    # A float can overlap other boxes in the normal flow (e.g., when a
>    # normal flow box next to a float has negative margins). When this
>    # happens, floats are rendered in front of non-positioned in-flow
>    # blocks, but behind in-flow inlines.
> which in turn requires that all inlines in the block formatting
> context be painted on top of all the blocks in that same block
> formatting context.
>
> I find it weird for this all-inlines on top of all-blocks behavior
> to cross between block formatting contexts (as it does for table
> cells

I actually don't find this so weird in the case of table cells, which is 
mainly why I'm on the fence when it comes to flex items.

I think each formatting context should be evaluated independently when 
considering whether or not it should establish a new pseudo–stacking 
context.  Note that since floats are "bound" to the non-inline 
formatting context to which they belong, so the implementer assistance 
that the pseudo–stacking context provides in relation to floats doesn't 
really apply in the case of table cells and flex items.  (I can't speak 
for other aspects of that assistance, though.)

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

Received on Thursday, 5 July 2012 07:34:03 UTC