Re: [css3-flexbox] is 'wrap-reverse' confusing?

On Thu, Jul 5, 2012 at 2:52 AM, Kang-Hao (Kenny) Lu
<kennyluck@csail.mit.edu> wrote:
> (12/07/05 12:55), fantasai wrote:
>> On 07/04/2012 08:34 AM, Kang-Hao (Kenny) Lu wrote:
>>> I have several proposal proposals from changing the 'wrap-reverse'
>>> keyword, reducing certain combinations or changing the whole syntax, but
>>> I'll stop here for now because there's only 30 minutes left for the
>>> telecoms and fantasai asked me to throw in all the substantive comments.
>>
>> We had lots and lots of conversations about this whole thing awhile back,
>> how to represent all possible combinations, and make it understandable.
>> The full set we came up with can be seen [1] here:
>>
>> http://dvcs.w3.org/hg/csswg/raw-file/aaab808294de/css3-flexbox/Overview.html#flex-flow
>>
>> At this point there was only 'flex-flow'. Later the physical values were
>> dropped, and, since this made invalid combinations impossible, the property
>> was split into 'flex-direction' and 'flex-wrap', with 'flex-flow' as a
>> shorthand.
>>
>> I doubt we'll change it at this point, but if you think you have something
>> substantially better, I suppose you can try to convince the WG. :)
>
> Thanks for the link. That was a good summary of all the values we had,
> and it inspires me to throw in yet another proposal :), although I
> wouldn't say it's substantially better. Proposed syntax for 'flex-flow':
>
>   [ row | row-reverse ] && [ wrap | wrap to head ]?
> |
>   [ column | column-reverse ] && [ wrap | wrap to start | wrap to end ]?
> |
>   [ wrap | wrap to head ]
>
> The default values are as usual, the syntax has the following
> characteristics:
>
>   * The keywords are all logical, although I am sure I can say the
> syntax is purely logical.
>   * 'reverse' always reverses the main-axis (renaming the keyword
> 'wrap-reverse' would have the same effect, but it's out of my capability
> to come up with a synonym of "reverse"). As a result, there is no longer
> 'row wrap-reverse', which I consider a confusing combination. You have
> to do 'wrap to head' now.
>   * For a 'column', you can optionally add the extra "wrap to end" if
> you feel like you can't remember which direction is the default
> cross-end. In other words, instead of the 'wrap(-normal)'/'wrap-reverse'
> switch, it is now a 'wrap to start'/'wrap to end' switch. This is, I
> think, less biased towards a direction: this is similar to the fact that
> the value of 'direction' is 'ltr'/'rtl' instead of 'normal'/'reverse'. A
> paragraph of vertical Chinese embedded in a document of 'writing-mode:
> horizontal-tb' would wrap its lines to left, so it's a bit harder for me
> to remember that the default wrapping of 'column' is 'wrap to end'.
>
> Some drawbacks:
>
>   * For 'column', it might be difficult to remember that 'wrap to start'
> is the 'start' side of the parent but not of itself.
>   * I haven't thought of how to split this to two properties.
>   * Having the special 'to' syntax in a value not within a functional
> notation is somewhat unprecedented. That was inspired by the link above.

I'll start by saying that I'm extremely disinclined to make any syntax
changes that aren't related to fixing an error in the spec.  Mild,
arguable improvements to the usability of a name aren't worth
disturbing the syntax at this point in the spec's life.

Responding to the actual proposal, I don't find it an improvement.  I
don't think it's worse, it's just not better.  "wrap-reverse"
parallels row/column-reverse - I think the fact that it means exactly
the same thing makes it easier to learn and remember. If we were to
change wrap in this way, I'd want to change row/column in the same
way, with optional "to start/end/head/foot" values as appropriate.

~TJ

Received on Friday, 6 July 2012 07:25:27 UTC