RE: Box Reordering

Not really. As it is, having reordering in Flexbox complicates implementation.

I predict that somebody will fill a Flexbox with thousands of items and then use box-ordinal-group for sorting, and expect reasonable performance. Then Flexbox layout not only needs a secondary storage for child order and quicksort. Neither is rocket science, but if it needs to be there it really should have a strong reason.

I am not saying there is no reason for it. But I personally don't think there is a strong reason for it.

From: jamesr@google.com [mailto:jamesr@google.com] On Behalf Of James Robinson
Sent: Monday, May 24, 2010 6:09 PM
To: Alex Mogilevsky
Cc: Tab Atkins Jr.; www-style list
Subject: Re: Box Reordering

How is that statement any different when applied only to flexbox?

- James
On Mon, May 24, 2010 at 5:59 PM, Alex Mogilevsky <alexmog@microsoft.com<mailto:alexmog@microsoft.com>> wrote:
It would be a good idea to contain reordering within flexbox. Even there it seems optional. Applying it everywhere sounds interesting but it is a major complication for implementation and would need strong use cases.

> -----Original Message-----
> From: www-style-request@w3.org<mailto:www-style-request@w3.org> [mailto:www-style-request@w3.org<mailto:www-style-request@w3.org>] On
> Behalf Of Tab Atkins Jr.
> Sent: Monday, May 24, 2010 4:53 PM
> To: www-style list
> Subject: Box Reordering
>
> One of my coworkers was looking at my new flexbox draft, and asked me
> why flex-index was limited to flexbox children only.
>
> I didn't have a good answer for him.  Flex units are limited to flexbox
> children, because they don't work properly in normal flow (so far - I'm
> interested in seeing if we can do something reasonable with them later).  But
> does content-reordering cause any similar problems?
>
> It would certainly be *confusing* given a lot of current spec text that plays
> loose with the distinction between elements and boxes.  But I suspect that
> it's doable.  It may have to wait for a proper spec detailing the creation and
> structure of the box-tree from the element-tree, though, so we can
> unambiguously talk about element-tree order and display-tree order.
>
> Does this sound like something vaguely reasonable?  Should I worry about
> renaming flex-index to box-index to allow for this ability in the future?
> Should I leave it alone, and just define flex-index as a synonym for box-index
> if we end up doing this later?
>
> ~TJ