Re: [css3-flexbox] Typos in updated flexbox spec

On Wed, Sep 7, 2011 at 8:03 PM, Alex Mogilevsky <alexmog@microsoft.com> wrote:
> This is exactly the kind of argument I'd expect to have 'before' renaming keywords. I prefer that to 'start' renaming...

Apologies.  Given the consistency argument with Grid, I thought this
would be a non-controversial change.  I was wrong.


> So we have a few considerations to balance:
>
> 1) consistency with line direction and block direction keywords:
>        if main axis is similar to line direction (start-end),
>        then cross axis is similar to block direction (before-after)
> 2) consistency with text-align and vertical-align
>        text-align values apply to 'flex-pack' (start|end|center|justify)
>        vertical-align values apply to 'flex-align'(before|after|middle|baseline)
> 3) consistency of 'flex-pack' and 'flex-line-pack'
>        similar name calls for similar values
> 4) consistency with grid
>        which has complete functional symmetry for rows and columns,
>        same syntax, same algorithms,
>        no benefit from using different keywords for rows/columns
> 5) will a shortcut property for both direction ever make sense?
>        Then something like "flex-layout:row start middle" is more readable
>        than "flex-layout:row start center"
>
> Last time we have discussed this (when 2009 spec was the current spec and neither 'grid-row-align' nor flex-line-pack' existed), it were only (1) and (2) to think about, and "before|after|middle" seemed the most logical choice. So obvious in fact that I used in IE10 implementation (expecting that the spec will get fixed any day, which didn't happen, and now it is a hassle for people writing cross-browser stylesheets).

Yes, I agree it was a pretty easy choice at the time.  #3 and #4 have
changed things.

> Even with all additional issues, if one of the values is 'baseline', the property is already special enough, then it makes sense to include values that go with 'baseline', such as 'middle'.
>
> Including Grid in the mix makes it less obvious. Grid doesn't have a "main axis" though... What if Grid had 'baseline' as one of align values? Would it also make sense to have it on both row and column? Would it work if set on both and using mixed-writing-direction content? If it would, it would be an argument for start/end everywhere.

I don't see why it wouldn't work.  It's actually a little bit odd that
Grid *doesn't* have baseline.  It should have the same use-cases as
"vertical-align:baseline" on tables, and shares many/most of the
use-cases for "flex-align: baseline" on flexboxes.

> The argument for 'flex-pack' and 'flex-line-pack' having different values I am not buying. Same applies to 'text-align' and 'vertical-align', and I never thought that they should accept same values. They are totally different. Perhaps using plural 'flex-lines-pack' would further clarify the difference...

Really?  'flex-pack' and 'flex-line-pack' are *identical* in effect -
it's just that one aligns flexbox items, while one aligns flexbox
lines.  I consider it *really bad* to have those use different values.

Further, you make the argument above that since 'flex-align' has
"baseline", it should match the values of 'vertical-align'.  Why does
that argument not apply to 'flex-line-pack', since it has the
"distribute" value, same as 'flex-pack' (and basically identify to
"justify" on 'text-align')?

> Either way, I really want the syntax to get stable. I don't care what it is but I want to know that it won't change again. ***please*** get WG resolutions for syntax changes or this will never get to CR.

I want the syntax to be consistent, both internally and between
similar specs (that is, with Grid), and I find that slightly more
important than advancing as long as it doesn't delay things too much.
And it won't, because it's just a name change - nothing functional has
been altered.  Name changes are so minor that they'd only delay a CR
if we were literally *just* about to push a WD to CR.  Flexbox is
nowhere near that state yet, and won't be until I write the flexing
algorithm and get confirmation that it's sane.

(On that note, I did delete the old flexing algorithm and tried my
best to express the layout in independent chunks spread across the
properties like we discussed, but it just can't be done - there are
too many interconnections, and too many values that have to be
calculated multiple times (first as a hypothetical size to help
calculate something else, then later as the actual size *based on*
that something else).  It would have been complete gibberish to
authors, and very difficult to read properly for implementors.  I'd
appreciate feedback on the outline of the flexing algorithm currently
in the spec, though.)

~TJ

Received on Thursday, 8 September 2011 16:44:29 UTC