Re: [css3-flexbox] flex-flow bikeshed

On Tue, Aug 30, 2011 at 11:17 AM, Ojan Vafai <ojan@chromium.org> wrote:
> On Tue, Aug 30, 2011 at 9:30 AM, Tab Atkins Jr. <jackalmage@gmail.com>
> wrote:
>>
>> On Mon, Aug 29, 2011 at 4:03 PM, Ojan Vafai <ojan@chromium.org> wrote:
>> > flex-flow seems really complicated. Unfortunately, I don't have anything
>> > new
>> > arguments against having so many possible values.
>>
>> I know what you mean. :/  Unfortunately, there are explicit use-cases
>> for nearly all of the values (and the few that weren't given explicit
>> use-cases are justified by consistency).
>
> I reread all the threads about this and I'll admit to not being able to keep
> track of all the use-cases + the need for all these values. The thing I
> wonder is how much simplification we could get if we cut one or two of the
> more onerous use-cases. As it is, I think the current complexity hurts the
> common use-cases because web developers, for the most part, just won't get
> all this and will pick whichever option seems to work.
> I don't have a good enough grasp of how these values map to what use-cases
> to make a meaningful suggestion.

I can list a few.

For horizontal lists, like a toolbar, you obviously want the ability
to send it either ltr or rtl.  Apparently, when doing
internationalized layouts, you want to swap the ordering of things
based on the directionality of the text.  This argues for "horizontal"
and "horizontal-reverse".  The "-ltr" and "-rtl" variants are for
explicit directions when your content isn't tied to text and shouldn't
be reversed in the UI when the document's direction is different.

Vertical toolbars have basically the same use-cases and reasoning.

"row" is identical to "horizontal", except it responds to writing-mode
changes as well, so a UI designed for English text will rotate
automatically when applied to Japanese vertical text.  This is useful
for the same reasons that the direction-dependent horiz/vert values
are.

The wrap values have similar arguments.  If you're positioning a
vertical toolbar on the left side of the screen, you want new lines to
go toward the right, and the same, mutatis mutandi, for vertical
toolbars on the right, and horizontal toolbars on the top or bottom.

That said, I think we could probably get away with simplification.  I
don't think we actually need all the possible mixtures of physical and
logical.  We could probably get away with doing pure-logical and
pure-physical, like:

 [ row | row-reverse | column | column-reverse ]
 [ wrap | wrap-reverse ]?
|
 [ left | right ]
 [ wrap-up | wrap-down ]?
|
 [ up | down ]
 [ wrap-left | wrap-right ]?

The only problem is that the terseness of the physical directions
makes it seem easier to use them, especially the vertical ones, when
we'd like to encourage the logical directions.  Perhaps using
something like "horizontal-left" and "vertical-up" would help?  Or
maybe we could reuse the directional syntax from linear gradients!
"to left", anyone?

>> If you have an idea for a better syntax, suggest away!
>
> I don't have an issue with the syntax. It's just a lot of options that are
> hard to wrap your head around as a web developer. I don't think this
> actually adds much implementation complexity.

Yeah, I understand.

>>
>> Note that some
>> of the options that seem overly-long (like "horizontal-ltr", which
>> could just be "ltr") were done that way on purpose, to discourage
>> their use when they're not explicitly needed.  We believe that 'row'
>> and 'column' will usually be correct and will adjust in the way that
>> authors actually want, but if 'ltr' was available, they'd often reach
>> for that just because it's so short.
>
> With my web dev hat on, I would almost certainly use 'horizontal' or
> 'vertical' because those seem to have the clearest relationship to what I
> want to see happen (i.e. things flowing horizontally or vertically).

Yeah, and that's something I think we'd like to avoid if possible.

~TJ

Received on Tuesday, 30 August 2011 23:31:18 UTC