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 Saturday, 8 May 2010 00:55:24 UTC