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

Received on Wednesday, 30 November 2011 16:30:03 UTC