- From: Ojan Vafai <ojan@chromium.org>
- Date: Tue, 29 May 2012 19:57:58 -0700
- To: Alex Mogilevsky <alexmog@microsoft.com>
- Cc: "Tab Atkins Jr." <jackalmage@gmail.com>, Tony Chang <tony@chromium.org>, Sylvain Galineau <sylvaing@microsoft.com>, fantasai <fantasai.lists@inkedblade.net>, "www-style@w3.org" <www-style@w3.org>
- Message-ID: <CANMdWTvhqLFHE6-hX8pxNQEG3ikqvdHeWoh7YF-vc16MEENXYA@mail.gmail.com>
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
Received on Wednesday, 30 May 2012 02:58:49 UTC