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

Sorry for not responding to the various flexbox threads last week; I
was on vacation last week and I'm still catching up.

On Monday 2010-04-19 14:35 -0700, Tab Atkins Jr. wrote:
> Flex-inline and flex-block are based on the block progression
> direction and the writing-mode, and map to one of the first four
> values.

It seems clearer to say they're based on the inline progression
direction and the block progression direction.

> Default is flex-right (equivalent to current draft's
> box-orient:horizontal;box-direction:normal;).

Shouldn't it be flex-inline to correspond to the current draft?  At
least in Gecko's implementation, the direction of box-orient:
horizontal boxes is influenced by both 'direction' and
'box-direction'.

> Display Order
> =============
> 
> box-direction is dropped for now.  It seems to be clearer to specify
> the direction of flow directly in the display value.  I don't *think*
> that we've lost anything by this.

I presume you're also proposing to drop box-orient.

> box-align has its start/end values renamed to before/after.  It was
> necessary to change one of these two properties; you can't have start
> and end referring to perpendicular directions.  I chose box-align to
> be changed so that the mapping makes the most sense for the default
> values - before/after act like top/bottom by default, and start/end on
> box-pack act like left/right by default, just like they would in a
> page with normal english text.

I think this might cause more confusion than it fixes.

> Added box-clear property, which takes `start` and `end` values.
> box-clear forces a linebreak in a flexbox, regardless of the box-wrap
> value.  `start` pushes the element onto a new line, `end` pushes the
> *next* element onto a new line.  Ordinary line-wrapping takes place
> after box-clearing happens (that is, first we do all the explicit
> linebreaking caused by box-clear, then, if box-wrap is normal, we
> check if any line is long enough to need wrapping).

These feel to me much more similar to *-break-before/after than to
clear.  I'm a little skeptical of the use of the "clear" name.

> What's left
> ===========
> 
> There is a pending question concerning what the best directions for
> start/end/before/after to map to is, depending on the display value.
> Currently, here are my thoughts:
> 
> right: before is top, start is left
> down: before is left, start is top
> left: before is top, start is right
> up: before is left, start is bottom
> inline: before and start are equivalent to whatever the writing-mode
> says they are
> block: like inline, but before and start are swapped

I think start/end/before/after should depend on the block and inline
progression directions and not the box direction/orientation.  (I'm
thinking of things like margin-start/end/before/after.  Are you
thinking about some other use of these names?)

-David

-- 
L. David Baron                                 http://dbaron.org/
Mozilla Corporation                       http://www.mozilla.com/

Received on Monday, 19 April 2010 22:19:26 UTC