W3C home > Mailing lists > Public > www-style@w3.org > July 2011

Re: [css3-flexbox] getting multiline flexbox back into the spec

From: L. David Baron <dbaron@dbaron.org>
Date: Wed, 27 Jul 2011 09:54:42 -0700
To: fantasai <fantasai.lists@inkedblade.net>
Cc: www-style@w3.org
Message-ID: <20110727165442.GA21038@pickering.dbaron.org>
On Tuesday 2011-07-26 10:19 -0700, fantasai wrote:
> On 07/25/2011 11:46 AM, Tab Atkins Jr. wrote:
> >Here's a slightly different suggestion inspired by something Shane
> >worked out.  This one avoids any possible confusion with invalid
> >combinations, and I think is easier to read:
> >
> >flex-direction:<orientation>  [<horizontal-dir>  <vertical-dir>?]?
> ><orientation>  = _rows_ | columns | horizontal | vertical
> ><horizontal-dir>  = ltr | rtl | _forward_ | reverse
> ><vertical-dir>  = ttb | btt | _forward_ | reverse
> >
> >The first keyword, which is required, gives the general orientation -
> >the first two are writing-mode dependent, the latter two are physical.
> >  It specifies the axis on which the flexbox items will be laid out;
> >lines will be stacked in the opposite axis.
> >
> >The second and third keywords, which are optional, specify,
> >specifically, the direction in the (physical) horizontal axis and the
> >vertical axis.  By doing it this way, you avoid any of the "mixing
> >physical and logical" confusion - it's perfectly well-defined and easy
> >to mix them, since you're specifically saying "use the logical
> >direction in the horizontal axis" or whatever.
> 
> Actually, you're still making a mess. Even if it is a well-defined mess.
> 
>   flex-direction: rows forward reverse;
> 
> This will go forwards on the main axis if the writing mode is horizonal,
> and backwards on the main axis of the writing mode is vertical. That
> doesn't make any sense.

Given that people seem to want all of:
 (1) the ability to mix logical and physical directions (which I
     think you were the strongest advocate for)
 (2) the inability to specify logical swaps (which you say you're
     against here)
 (3) the inability to specify combinations that don't compute (i.e.,
     specify 2 vertical directions and no horizontal, or vice-versa)

perhaps the remaining option along this approach is to slightly
modify Tab's proposal to yield something that works a bit like
background-position's keyword-percent mixing rules:

flex-direction:<orientation>  [<dir>  <dir>?]?
<orientation>  = _rows_ | columns | horizontal | vertical
<dir>  = ltr | rtl | ttb | btt | _forward_ | reverse

in which the orientation is handled as above, but the directions are
handled according to the following rules:

 - if no directions are specified, both are 'forward'
 - if one direction is specified and it is logical, then use that
   direction for the primary direction and wrap in the forward
   direction
 - if one direction is specified and it is physical, then use that
   direction for either the primary or wrapping direction, as
   appropriate, and make the other (primary or wrapping) direction
   forward
 - if two directions are specified, both logical, then use the first
   for the primary direction and the second for the wrapping
   direction
 - if two directions are specified, one logical and one physical,
   then use the physical direction for either the primary or
   wrapping direction (as appropriate) and use the logical direction
   for the other
 - if two directions are specified, both physical, and they are on
   opposite axes, use them for the two directions (primary and
   wrapping) as appropriate
 - if two directions are specified, both physical, and they are on
   the same axis, this is a PARSE ERROR.

That said, an alternative here is to make wrapping control part of
this property.  This could be done, for example, by changing the
<orientation> production to:

 _row_ | rows | column | columns | horizontal | horizontal-wrap |
 vertical | vertical-wrap

If we did this, then this would impose some (relatively
straightforward) additional constraints on the one-direction forms
above.

-David

-- 
𝄞   L. David Baron                         http://dbaron.org/   𝄂
𝄢   Mozilla Corporation               http://www.mozilla.com/   𝄂
Received on Wednesday, 27 July 2011 17:39:42 GMT

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