Re: [css3-flexbox] Painting order

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.

Relying solely on z-index isn't great.  It's duplicated effort, for
one.  Second, you have to not only set z-index, but also set position,
as z-index does nothing on position:static items.

> Another related topic here is whether flex items should 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. This is unrelated to the
> 'order' property, though, and maybe we should start a new thread if it
> needs to be discussed.

Yeah, open a new thread please.

>>> (doesn't sound very pleasant to implement, either)
>>
>> It was trivial on our side, as we make 'order' literally reorder the
>> box tree (iiuc).
>
> The box tree still needs to be traversed in logical order if you're
> e.g. doing text selection, I suppose.

Text selection is definitely still DOM order.  I don't know the
mechanics of that in Chrome, but it's apparently not difficult.

~TJ

Received on Wednesday, 27 June 2012 23:32:35 UTC