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

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

From: Alex Mogilevsky <alexmog@microsoft.com>
Date: Wed, 18 Apr 2012 02:31:52 +0000
To: fantasai <fantasai.lists@inkedblade.net>, "www-style@w3.org" <www-style@w3.org>
Message-ID: <2C86A15F63CD734EB1D846A0BA4E0FC80E77E999@CH1PRD0310MB381.namprd03.prod.outlook.com>
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.

2) The generic alignment properties and values come from good motivation and have good ideas, but I have not yet seen a set that works smoothly across blocks, flexbox and grid. Some properties get values that are not applicable, some properties get renamed to something far less intuitive.

3) If flexbox uses properties that are meant to be applicable to blocks, any UA implementing flexbox also has to implement box alignment etc. for blocks, tables, etc. That would be awesome, but it won't make it faster either.

My preference is to keep layout specific properties with "flex-" and "grid-" prefixes. If/when we have a good stable spec for generic alignment, we can deprecate current properties or keep as synonyms. There is a precedent already with "page-break-before:always" == "break-before:page", that's not ideal, but I would rather have more of that make rush decisions now on important features.


Received on Wednesday, 18 April 2012 02:33:31 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:08:14 UTC