W3C home > Mailing lists > Public > www-style@w3.org > April 2012

Re: [css3-flexbox] One final round of bikeshedding on property/value names?

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Thu, 19 Apr 2012 11:14:51 -0700
Message-ID: <CAAWBYDCx=4QROarJBF4LgiY42okhXs3Q8zduWnRjH12vS-iuPA@mail.gmail.com>
To: Alex Mogilevsky <alexmog@microsoft.com>
Cc: fantasai <fantasai.lists@inkedblade.net>, "www-style@w3.org" <www-style@w3.org>
On Tue, Apr 17, 2012 at 7:31 PM, Alex Mogilevsky <alexmog@microsoft.com> wrote:
> From: fantasai [mailto:fantasai.lists@inkedblade.net]
> ± Sent: Tuesday, April 17, 2012 6:52 PM
> ±
> ± > Le 17/04/12 01:33, Tab Atkins Jr. a écrit :
> ± >> fantasai proposes renaming all of the alignment properties and some
> ± >> of their values:
> ± >>
> ± >> 'flex-align' becomes 'content-align'
> ± >> 'flex-item-align' becomes 'box-align'
> ± >> 'flex-line-pack' becomes 'content-pack'
> ± >> 'flex-pack' becomes 'content-justify'
> ± >
> ± > Well, I also see a lot of value in keeping the flex-* prefix. It adds
> ± > readability, it helps the learning curve, it helps maintainance
> ± > because all flex-box properties are easy to search for with one
> ± > pattern only...
> ±
> ± Please refer to the original email. There's a lot of points of confusion
> ± around having so many alignment properties. I really feel it is better
> ± for an author to only every have to learn one set.
> ±    http://lists.w3.org/Archives/Public/www-style/2012Feb/0743.html
>
> I think I am open minded to any naming changes, even though I am already used to what we have. I have a couple of issues with what is being proposed though:
>
> 1) Switching to generic alignment properties pushes flexbox spec to define generic functionality that is outside of its scope, or makes it dependent on a generic alignment spec, which doesn't exist, and if it existed it would not be anywhere close to LC. It may not be as scary as it appears to me, but if we make this kind of change now we shouldn't even have flexbox LC on the agenda for a while.

This is my concern as well, more or less.

If we switch to a set of generic properties, we either have to
(a) define their meaning for block/table/etc *in the Flexbox spec*, or
(b) leave that to a later spec, and pray to our gods that authors
don't pollute them in the meantime.

I don't want to do (a), because that means delaying Flexbox further
while we discuss details.  I estimate that would add at least a few
months to Flexbox stabilizing.

I don't want to do (b) either, because I'm not confident that they
won't get polluted.  I don't have time to work on the Block Layout
spec anytime soon, and I don't think anyone else does either. :/

As such, I think the right course of action right now is to keep
Flexbox with flexbox-specific alignment properties.  (However, I'm
amenable to renaming them to be closer to the generic names, to ease
eventual migration.)

We should continue to work on these generic properties, though, so
that they're ready for production before Grid hits this point.  This
means we need someone to at least write up a small spec defining their
effect on the 2.1 display types.

I'm aware that this means we'll have to alias the Flexbox properties
at some point.  I consider this unfortunate but necessary if we don't
want to delay Flexbox by several months.  (If you'd like to avoid
this, please write the spec I outlined above before Flexbox's LC
period is over and get the WG to sign off on it.)  Assuming the spec
gets written soon enough, we can change Grid over and avoid aliasing
there too.

~TJ
Received on Thursday, 19 April 2012 18:15:43 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 17:20:52 GMT