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

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

From: Stephen Zilles <szilles@adobe.com>
Date: Wed, 30 Nov 2011 08:29:31 -0800
To: Alex Mogilevsky <alexmog@microsoft.com>, "Tab Atkins Jr." <jackalmage@gmail.com>
CC: "www-style@w3.org list" <www-style@w3.org>
Message-ID: <CE2F61DA5FA23945A4EA99A212B157954AE1906CB6@nambx03.corp.adobe.com>
I think I understand and agree with the proposal for 
  flex: [ <pos-flex> <neg-flex>? ]? || <preferred-size>?

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.


± 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 16:30:03 GMT

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