RE: Fw: RE: [css-flexbox] Summary of planned changes to Flexbox Module

Here is my take on the proposed changes (discussed with Sylvain and Arron).

First, most changes are good (except the ones I don’t agree with;). In ideal world, before flexbox is finalized (in old or new or any other form) it would be great to have a consistent story with template/grid layout or whatever supersedes those. It seems clear that there will be a new model there eventually, when it is it better be in sync with flexbox. We should discuss that in next F2F and ideally have at least some idea on where all of the above are moving.

Specifically on the proposed changes:

• I like the change of “box” to “flexbox”. It makes more sense
•	I *really* don’t like the attempt to switch from additive (flex values distribute the extra space after STF sizes are calculated) to absolute (no STF, flex distributes all space). I see it discussed, but I can’t track where exactly it was proposed, if it was… Additive nature of flex is the most elegant part of the design IMO.
• Also it appears flex becomes a “flex unit” and applies to more stuff, like margins (I also see it mentioned but don't see where it is proposed). It sounds like added complexity which would need to be justified.
• Dropping flex-group is good (it is hard to explain what it is for, and use cases are not too strong).
• Changing “box-lines” to “flexbox-wrap” sounds more intuitive. 
• Flexbox-break-* is a new feature, good to have
• Replacing box-direction and box-orient with flexbox-begin I don’t like. It doesn’t make it more intuitive; it may be more elegant and solve reverse orthogonal direction problem, but I think that last problem would be better solved with an extra property. "begin" property may even match internals of a reasonable implementation better, but in API simple things should be simple. I would much rather see something like this:

-- flexbox-orientation: horizontal | vertical | inline-axis | block-axis (fully-spelled 'orientation' is better than 'orient')
-- flexbox-direction: normal | reverse
-- flexbox-align-direction: normal | reverse (a new property to control orthogonal direction)

"orientation" should be the most used property. "direction" and "align-direction" will be used sparingly, and shouldn't distract from the most common use case.

Thanks for working on the spec Tab, hope to see a new editor draft soon
Alex

-----Original Message-----
From: www-style-request@w3.org [mailto:www-style-request@w3.org] On Behalf Of Tab Atkins Jr.
Sent: Friday, May 07, 2010 5:55 PM
To: Adam Del Vecchio
Cc: www-style@w3.org
Subject: Re: Fw: RE: [css-flexbox] Summary of planned changes to Flexbox Module

After discussions with both dbaron and fantasai, I think I've settled on a more ideal rearrangement.  It's somewhat more radical, but I'm fairly convinced that it's *significantly* more elegant.

Several of the changes I discussed previously still stand.  There are two major differences:

1) I've dropped back to a single new display-inside value, "flexbox".
Additionally, a flexbox-begin property (name subject to change) determines which edges flexbox children are initially placed against.
The grammar is [ [[top | bottom] && [left | right]] | [[start | end] && [before | after]] ] - in other words, it must be a perpendicular pair of either physical edges or logical edges.  The first value determines the "packing start edge" so that, frex, a value of "top"
would be a standard vertical flexbox.  The second value is the side they're aligned against.  The defaults would be "start before" - that is, for a normal page, they start being packed against the left edge new boxes go to the right of it, and are aligned against the top edge and new lines stack below it.  Also, this property will probably accept a single value, which will then automatically choose the start or before edge as appropriate.

2) I'm abandoning box-align, box-pack, and box-flex in favor of flex units.  Flex units really are the right solution here, I think.  The algorithm to determine the flexes is roughly the same as what already exists in the spec (at least, it's not more difficult), but the uses are more flexible.  For example, you can flex a margin to shove some boxes against the left edge and others against the right edge, which is a pattern seen fairly commonly in the top-links on webpages.  You can flex height/width to duplicate box-align:stretch, or you can do the same with padding and also shove the content to the top, bottom, or center of the box.  There were two values that caused trouble initially - box-pack:justify (in multiline flexboxes) and box-align:baseline.  The former can be addressed by the margin-break property (discussed at Tokyo '09) to discard the appropriate margins of the boxes on either side of the break.  The latter can be addressed by allowing vertical-align to apply to flexbox children, in the exact same way that it applies to table-cells.

When you look at all the properties taken together, it becomes pretty obvious that this is probably the optimal solution to slice up this
functionality:

display-inside: flexbox
flexbox-order: <integer> (1)
flexbox-wrap: wrap | nowrap (nowrap)
flexbox-break-before: always | avoid | auto (auto)
flexbox-break-after: always | avoid | auto (auto)
flexbox-begin: [ [[top | bottom] && [left | right]] | [[start | end] && [before | after]] ] (start before)

Except for flexbox-begin, which is a rather unique property, all of the remaining properties conceptually map to a similarly-named property that already exists in CSS.  -order is like z-order (just in a different direction), -wrap is like text-wrap (which doesn't exist, but *should*, taking some of the values from white-space), and
-break-* is just like the page/column break properties.  Flexing width/height/padding/margin then acts in a pretty intuitive way as well.

I feel pretty strongly that this sort of change is worth breaking the current experimental implementations in Gecko and Webkit.

I should be able to write a new draft sometime next week.

~TJ

Received on Tuesday, 11 May 2010 06:23:20 UTC