W3C home > Mailing lists > Public > www-style@w3.org > April 2010

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

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Mon, 19 Apr 2010 15:44:02 -0700
Message-ID: <x2wdd0fbad1004191544i2cc14681v59d64cf23ecffb83@mail.gmail.com>
To: "L. David Baron" <dbaron@dbaron.org>
Cc: www-style list <www-style@w3.org>
On Mon, Apr 19, 2010 at 3:18 PM, L. David Baron <dbaron@dbaron.org> wrote:
> Sorry for not responding to the various flexbox threads last week; I
> was on vacation last week and I'm still catching up.

No problem!


> 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.

Sure.


>> 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'.

Gah, right.  Somehow got mixed up and thought the default was
"horizontal" in the current draft.


>> 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.

Yes.  Sorry, I dropped that in my head so long ago I forgot that I
needed to call it out.  ^_^


>> 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.

Really?  I find it sort of confusing that start/end, which are
typically used in the context of text direction, would be used to
refer to perpendicular directions here.

It's possible that names other than start/end/before/after would be
more appropriate, but the layout of a flexbox is generally similar to
the layout of text on a line, so that seemed the most natural to me.
At the very least, though, I'd want different words for the align and
pack directions.


>> 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.

Yeah, the concepts are similar.  It's possible to use a
*-break-before/after concept instead.  It would just require an
appropriate name.  line-break-before/after?

Using this set of concepts instead of the "clear" concept would allow
us to drop the box-wrap property, too.  The default value for both
properties would just be "never", producing the standard single-line
form.  You can cause wrapping by setting "auto" on all the children of
a flexbox, and "always" to produce explicit breaks.


>> 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?)

No, I'm thinking of the same use of the names.  I'd like a
physical-direction-agnostic name for the directions, though, to make
it simpler to talk about.  The current draft just explicitly talks
about both horizontal and vertical every time (well, it skips vertical
a lot, but it *could* talk about both all the time) and then
explicitly talks about what to do when box-direction:reverse is
specified.

I don't particularly want to invent a *third* set of directional
words, though.  If using start/end/before/after is too confusing, we
can just explicitly lay out every case in the draft, like the current
draft does.

~TJ
Received on Monday, 19 April 2010 22:44:55 GMT

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