W3C home > Mailing lists > Public > www-style@w3.org > November 2011

RE: [css3-flexbox] remove flex() function

From: Alex Mogilevsky <alexmog@microsoft.com>
Date: Wed, 30 Nov 2011 00:13:49 +0000
To: Tab Atkins Jr. <jackalmage@gmail.com>
CC: "www-style@w3.org list" <www-style@w3.org>
Message-ID: <D51C9E849DDD0D4EA38C2E539856928412D7690C@TK5EX14MBXC218.redmond.corp.microsoft.com>
± From: Tab Atkins Jr. [mailto:jackalmage@gmail.com] 
± Sent: Tuesday, November 29, 2011 11:42 AM
± >
± >   1) flex() was intended to be used on more properties (margins,
± >      padding). Adding separate properties for
± >      each flexible length would be excessive then.
± >   2) flex(<flexibility> <preferred-size>) was expected to be more
± >      intuitive than separately setting preferred
± >      size. In particular "flex(1)" is supposed to read
± >      better than "width:0; flex:1;"
± >
± I disagree in the strongest terms.  (2) is not "expected to be more intuitive".  
± We *know*, with tons of examples (including our own
± chair!) that authors find it confusing if width/height and flexibility are 
± separate properties.  Combining them removes the possibility for confusion.  
± We've had this discussion before, and I don't really want to rehash it.  There 
± are benefits to separating them, but they're massively outweighed by the well-
± established author confusion from doing so.

You don't need to disagree with my wording of (2). I have no intention to downplay the value of providing a clear way to specify preferred-width and flexibility together.

I have a problem with flex() having much bigger side effects than we have previously realized. At the same time, I see that we can achieve same goals by using same patterns as elsewhere in CSS.

± I agree that flex() has some less-than-ideal properties.  In particular, I'm not 
± wild about it being usable outside of flexboxes, and I don't like that it has to 
± be specified as a physical dimension when it only applies to the flexbox's main 
± size, which maps to a physical dimension based on other properties.


± We can possibly fix this in other ways, if it's really desirable.  For example, 
± we could have a 'flex' property that takes the same syntax as the flex() 
± function and which applies *instead of* width/height (whichever is appropriate).  
± This would solve both of the problems I complained about above, and a few more 
± of your issues.  It could also be turned into a shorthand later (or now), 
± allowing independent cascading of the different pieces.

I like the idea 'flex' property much more than 'flex' function. That IMO is totally "CSS way".

	flex: [ <pos-flex> <neg-flex>? ]? || <preferred-size>?

Would work fine for me. It avoids most of the issues.

We'll want "preferred-size" here would override respective 'width' or 'height' for flexbox calculation, but not affect 'width' or 'height' properties in cascading. Agree?

To really make me happy here it should actually be a shortcut for separate properties:

	flex-positive: <number> 	
	flex-negative: <number> 	
	flex-preferred-size: <length>

This way the DOM story for it is completely straightforward, and they can be separately cascaded and animated too.

How does that sound?


Received on Wednesday, 30 November 2011 00:14:33 UTC

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:38:52 UTC