Re: Box Reordering

On May 24, 2010, at 7:20 PM, fantasai wrote:

> On 05/24/2010 04:53 PM, Tab Atkins Jr. wrote:
>> 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?
> 
> To me, 'flex-index' sounds like property that controls flex, not one
> that controls box order.
> 
> Just sayin'.
> 

Agreed. flex-index is not a good name for a box ordering property (assuming this is the property that was originally box-ordinal-group).  The property has nothing to do with flexing.

In some versions of the box proposal there were flex groups, which really were about controlling ordering of flex (in order to create multiple flex categories).  When I hear "flex-index" that is what I think of... not box reordering.

dave
(hyatt@apple.com)

Received on Tuesday, 25 May 2010 00:54:42 UTC