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