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

I should have said thank you first for making awesome progress on editing the spec and getting it into shape. Thank you!

I don't think we need to discuss impact of syntax changes hypothetically. Let's just start with getting a consensus on syntax between the editors as soon as we can, then it will have a decent shot with WG. I'll write up some options for the pack/align property set and will get back to discuss. It may not even change what you have, I still want to see options and reasoning. Does that sound ok?

And I agree that grid should have baseline alignment defined, I'll include that as well.

Is this the only part of the syntax that you wanted to improve? Any other syntax issues that you are not perfectly happy about?
 
Alex

-----Original Message-----
From: Tab Atkins Jr. [mailto:jackalmage@gmail.com] 
Sent: Thursday, September 08, 2011 9:44 AM
To: Alex Mogilevsky
Cc: www-style@w3.org
Subject: 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 17:46:16 UTC