Re: [css3-flexbox] Painting order

On 28/06/2012 11:39, Morten Stenshorne wrote:
> "Tab Atkins Jr." <jackalmage@gmail.com> writes:
>
>> On Wed, Jun 27, 2012 at 1:57 PM, Morten Stenshorne <mstensho@opera.com> wrote:
>>> "Tab Atkins Jr." <jackalmage@gmail.com> writes:
>>> I was thinking that we don't do the same paint reordering for
>>> table-row-group, table-header-group and table-footer-group. (Well, both
>>> IE and Opera do it, but I believe that's a bug, since there's nothing in
>>> the spec that suggests such behavior). Then again, it's probably not so
>>> interesting to change between those display types dynamically. But
>>> consistency is nice. Why is it necessary to let 'order' affect painting
>>> order for flex items, when there already exists a mechanism to do so
>>> (z-index)?
>>
>> You're right, it would make sense to say the same thing about
>> table-header/footer-group.  We should raise this as an issue.
>
> I still think painting in tree order by default is the right thing. I
> think it's predictable and consistent (and generally easier to
> implement, since you HAVE to traverse them in logical order under some
> circumstances anyway).
>
> And what about BIDI reordering, then?
> http://www.w3.org/TR/CSS21/zindex.html#stacking-notes says that they are
> painted in tree order (but positioned in visual order).
>
>> Relying solely on z-index isn't great. It's duplicated effort, for
>> one.
>
> This is only an issue when you have overlapping items. Why does it have
> to be so convenient to achieve something that obscure, that we have to
> leave the principle of painting in tree order (when there already are
> mechanisms to achieve that if you really want it differently)?
>
>> Second, you have to not only set z-index, but also set position,
>> as z-index does nothing on position:static items.
>
> I've wondered about that. Why does it have to be like that? Opacity and
> transforms may already turn otherwise regular statically positioned
> boxes into stacking contexts and also make them participate in the
> painting order regime previously (CSS 2) reserved for positioned
> boxes. Why couldn't z-index just apply to all elements?

Yes, I think it's widely accepted that having z-index apply only to 
positioned boxes was a mistake.  We definitely can't change that now; 
stylesheets are littered with useless z-index declarations on 
non-positioned boxes, and suddenly making them have an effect would be 
damaging.

I don't have a strong opinion on whether painting should happen in tree 
order or visual order; I think both are reasonable behaviours.  It's 
hard to tell whether one behaviour would be more surprising to authors 
than the other.  My own gut feeling is that visual order is the less 
surprising.

Bear in mind that CSS21 Appendix E defines tree order as being a 
traversal of the *rendering* tree [spec's emphasis] "after taking into 
account properties that move boxes around".  (With an exception for 
BIDI.)  So actually I think that visual order is already specified 
here... not that it's clear which properties (if any) in CSS21 count as 
"moving boxes around", or whether that includes the table-*-group magic.

On a related note, if a flex item doesn't count as a "block equivalent" 
then we have to say in css3-flexbox how flex items fit into the Appendix 
E algorithm.  There's already a bug filed on what "block equivalent" 
means; my suggestion now is to add an errata to CSS21 defining *exactly* 
which CSS21 box types are block equivalents, and noting that future 
specs may define new box types as being block equivalents.  Then we'd 
define flex items to be block equivalents for the purposes of Appendix E.

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

Received on Monday, 2 July 2012 20:15:32 UTC