- From: fantasai <fantasai.lists@inkedblade.net>
- Date: Tue, 29 May 2012 09:19:43 -0700
- To: www-style@w3.org, "L. David Baron" <dbaron@dbaron.org>
On 05/24/2012 03:33 PM, Tab Atkins Jr. wrote: > On Thu, May 24, 2012 at 3:29 PM, Tony Chang<tony@chromium.org> wrote: >> >> That said, flex-basis: auto is about twice as slow as flex-basis: 0 (or any >> other fixed value). This is because before you can do the flex algorithm, >> you need to compute the the basis (layout the child), then after you've run >> the flex algorithm, you have to do a second layout at the computed width. >> >> 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. A flex-basis of zero doesn't play very well with multi-line flexbox, as it forces all the items to take their min-content width before computing line breaks. Also, I'm not sure that calculating max-content requires a full layout any more than min-content does. Theoretically, it just requires keeping a running total as you calculate the inline min-content lengths, and resetting that total when you hit a forced break, right? (dbaron would know for sure: if it's possible to optimize that way, I suspect Gecko has done it.) ~fantasai
Received on Tuesday, 29 May 2012 16:20:23 UTC