W3C home > Mailing lists > Public > www-style@w3.org > May 2010

RE: Box Reordering

From: Alex Mogilevsky <alexmog@microsoft.com>
Date: Tue, 25 May 2010 00:59:06 +0000
To: Tab Atkins Jr. <jackalmage@gmail.com>, www-style list <www-style@w3.org>
Message-ID: <5258A1A783764C478A36E2BC4A9C497E0A5B8B@tk5ex14mbxc105.redmond.corp.microsoft.com>
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] 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

Received on Tuesday, 25 May 2010 00:59:44 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 17:20:27 GMT