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

Alex, I see what you're saying now. I was wrong about the performance
impact for row. The performance impact of flex-basis:auto *only* applies to
column. You need to layout once to get the flex item's height, then flex
the height, then layout again for any descendants of the flex item that
depend on the height (e.g. % heights). It's true that the second layout can
be cheaper than the first for most cases if you do the right optimizations,
but there are legitimate cases where it would be expensive.

In a world where you flex by default, I suppose flex-basis:auto is
sensible. However, we believe that "flex:0 0 auto" is simply what web
developers will want and expect for nearly all cases because there will be
only a single flexing item in the flexbox. In the old scheme of defaulting
"flex: 0 0 auto", most UIs would only need to set "flex: 1" on a single
item and not need to set flex on any other items.

Also, flex-basis:auto is hard to wrap your head around. That was my
experience as a web developer writing pages towards the old flexbox API and
that has been my experience writing test cases for the new flexbox API.
flex-basis:auto consistently led to surprising layouts.

That all said, we're willing to concede here:
1. The performance isn't as bad as we initially thought, although there are
still cases where it's quite a bit worse.
2. fantasai's original comment that most people will just set "flex:none"
or "flex:1" on all the children anyways is compelling (i.e. people will
effectively get flex-basis:0 because that's what the majority of UIs will
want).  However, it seems silly to require the majority of pages using
flexbox to set "flex:none" on every flex item when all they want is "flex:
0 0 auto" for all items except the one item that will flex.

Ojan

On Wed, May 30, 2012 at 11:43 AM, Alex Mogilevsky <alexmog@microsoft.com>wrote:

>  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>
> wrote:****
>
> ± 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.****
>
> ** **
>
> 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****
>