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

I think I understand and agree with the proposal for 
  flex: [ <pos-flex> <neg-flex>? ]? || <preferred-size>?
Below.

If we would expect that we might want to allow flexing of other aspects of the box model, other than content size, I would suggest that the property name be "content-flex" and that it apply, as suggested, in the appropriate direction only in flexbox layout.

Steve Z.

-----Original Message-----
From: Alex Mogilevsky [mailto:alexmog@microsoft.com] 
Sent: Tuesday, November 29, 2011 4:14 PM
To: Tab Atkins Jr.
Cc: www-style@w3.org list
Subject: RE: [css3-flexbox] remove flex() function

± 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.

Exactly.

± 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?

Alex