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

RE: [css3-flexbox] flex-basis initial value should be 0px

From: Alex Mogilevsky <alexmog@microsoft.com>
Date: Wed, 30 May 2012 00:48:04 +0000
To: Tab Atkins Jr. <jackalmage@gmail.com>, Tony Chang <tony@chromium.org>
CC: Sylvain Galineau <sylvaing@microsoft.com>, Ojan Vafai <ojan@chromium.org>, fantasai <fantasai.lists@inkedblade.net>, "www-style@w3.org" <www-style@w3.org>
Message-ID: <2C86A15F63CD734EB1D846A0BA4E0FC823C9861E@CH1PRD0310MB381.namprd03.prod.outlook.com>
± From: Tab Atkins Jr. [mailto:jackalmage@gmail.com] 
± Sent: Thursday, May 24, 2012 3:34 PM
± 
± > I would prefer that the initial value of flex-basis be 0.  As Tab 
± > mentioned up thread, this won't cause overflow anymore than flex-basis: auto.
± 
± If dealing with the min-content restriction is indeed much cheaper than a full 
± layout in WebKit (I already know that it's cheaper in FF), then yeah, I don't 
± see any particular reason to default to 'auto' over '0'.  They're equally safe, 
± and neither seems to be obviously more desirable as a default layout strategy.  
± Favoring the faster layout system here seems like a win.

I am also confused, as Anton earlier, why we are making a decision based on what's faster in Webkit rather than defining what is a better behavior. I browsed through this thread but I don't see convincing use cases either way.

BTW I am not sure how Webkit or FF approach min-content, but in IE it takes same time to get min-content as it is to get max-content. They are calculated together, an important optimization that we always had for tables.

Also note that in column-direction flexbox this alleged perf difference will never apply.


To me, it seems that default flex-basis of 'auto' makes perfect sense. As everywhere else, if you don't specify width and height, boxes become whatever size they want to be, or something derived from that. "All items are of the same size" seems way too specific for default behavior...

Alex

Received on Wednesday, 30 May 2012 00:49:49 GMT

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