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

My understanding of proposal of "zero default flex-basis" is that it includes "default min-width/min-height is min-content". A default with min size also being zero is of course faster, but it really seems not very useful.

Assuming my understanding is correct, calculating min restriction does require work, and it is same amount of work (or approximately same) as calculating max-content. Any disagreement on that?

From: ojan@google.com [mailto:ojan@google.com] On Behalf Of Ojan Vafai
Sent: Tuesday, May 29, 2012 7:58 PM
To: Alex Mogilevsky
Cc: Tab Atkins Jr.; Tony Chang; Sylvain Galineau; fantasai; www-style@w3.org
Subject: Re: [css3-flexbox] flex-basis initial value should be 0px

On Tue, May 29, 2012 at 5:48 PM, Alex Mogilevsky <alexmog@microsoft.com<mailto:alexmog@microsoft.com>> wrote:
± From: Tab Atkins Jr. [mailto:jackalmage@gmail.com<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.

Is flex-basis:0 not faster than flex-basis:auto in IE? Unless your fixed size implementation doesn't do straightforward optimizations (and thus is slow), it seems fundamental to me that auto is considerably slower. It requires two layouts of the content instead of one. It's conceivable to me that, with sufficient optimization, you could make it so that it's not twice as slow, but it will still be slower in many cases.

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.

The point is that you don't need to compute either for flex-basis:0 + no min-content restriction. But, we've already said we're OK with min-width/min-height of min-content. It's flex-basis:auto as the default that we have a problem with.

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

Are we talking about min-content/max-content or flex-basis:auto? For the latter, the perf difference still applies as best I can tell. You still need to do an extra layout.

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

There are legit use-cases for both and I don't think that flex-basis:auto is a more common use-case. I don't really see what you mean by what size the boxes want to be. In my world view, flexboxes by default want to be the size based solely off the flex, not the auto size + the flex. I think this is even the common case, but I don't see any way of objectively proving that one way or another. You can argue it either way. It's subjective and arbitrary, unlike the performance.

It's not like we're saying they should default to 10px or something. 0 is a special case that gets a layout that people will commonly want when using flexboxes.

Ojan