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

On Wed, May 23, 2012 at 11:23 AM, Tab Atkins Jr. <jackalmage@gmail.com>wrote:

> On Wed, May 23, 2012 at 11:04 AM, Tony Chang <tony@chromium.org> wrote:
> >> Ojan, Tony, when you say that 'flex-basis:0' is cheaper than 'auto',
> >> are you keeping in mind that, by default, flexbox items will have a
> >> min-width/height value of 'min-content'?  I don't know if we
> >> fast-track that for width, but it seems to require at least *some*
> >> layout-level computation.  For column flexboxes, the min-height seems
> >> to require a full layout anyway.
> >
> > Huh, I totally missed section 4.4 about the implied min size.  I see it
> now
> > in the minutes sent on May 15th.
>

I also missed this. This, as well as auto being the default flex-basis,
both make sense when you consider only toolbar use-cases of flexbox where
there is little content in each flex item. But in use-cases where you have
more content (e.g. column layouts), doing a second layout can be a
significant performance penalty.


> > I understand the desire to avoid overflow, but it has the cost of making
> > layout slower by default, even if there's no overflow.  I'm not sure it's
> > worth it.  I would rather authors have to opt-in for slower behavior to
> > avoid overflow by setting min-width to min-content explicitly.  That
> seems
> > more consistent with how min-width works everywhere except for tables.
> >  Also, I think one of the reasons people don't use table layouts much
> > anymore is because of slow cases like this.
>
> :/ The problem with making the default behavior bad in corner cases is
> that people generally won't flip switches they don't have to, so when
> the corner case comes up, most people will end up with bad behavior.
>
> You can definitely opt into the "shut up, I know what I'm doing, 0 min
> size" by setting "min-width: 0;" explicitly.  I generally prefer
> making the default behavior safe-but-slightly-slower and giving people
> the option to flip a "speed it up" switch that's slightly more
> dangerous.
>

This is the part I disagree with. When we break an edge case visually, it's
relatively straightforward for a developer to look up the documentation for
flexbox (e.g. on MDN) and figure out how to fix it. On the other hand, when
the performance is slow, it's almost impossible to gain insight into what's
causing it to be slow. As a web developer, you're most likely to throw your
hands up and assume the UA just hasn't optimized flexbox, at which point
you'll either not use flexbox or live with your site being slow to load,
both of which are unacceptable.

As with all things, there are tradeoffs. Requiring a second layout by
default is not an acceptable tradeoff for the marginal extra safety we get
for uncommon edge-cases.

If the speed it up switch were an obvious part of the API (e.g.
flex-box-speed: fast), then I might have a different opinion. But
understanding what makes flexboxes fast or slow is extremely complicated.
It requires both understanding the spec in detail and understanding
which optimizations a browser vendor does (e.g. there are a bunch of cases
where a naive implementation would do multiple unnecessary layouts). I
can't imagine anyone other than the browser developers implementing flexbox
to have this sort of detailed knowledge.


> > As a web author, if I'm trying to do a grid line layout using flexbox, I
> > think I would want to overflow rather than mess up the grid.  For
> example,
> > if I had a header align to a grid and I wanted the footer to align to the
> > same grid using a different flexbox, I would want to overflow.  Maybe
> this
> > is just an argument for using grid layout, but I think that's more
> > complicated and overkill for many sites.
>
> Note that the grid only gets "messed up" if the screen is small enough
> to make some of the items less than their min-size.  min-size only has
> an effect when an item tries to shrink below it; during normal flexing
> it has no effect.
>
>
> >> On Wed, May 23, 2012 at 1:48 AM, Anton Prowse <prowse@moonhenge.net>
> >> wrote:
> >> >> On the other hand, they merely *seem* indistinguishable for another
> >> >> common case, where each of the items has a short amount of text. On a
> >> >> large screen, they may seem approximately equal in both situations,
> >> >> but on a small screen, the "flex: auto" behavior is better, since it
> >> >> won't cause overflow on any of them until absolutely necessary.
> >> >
> >> > For navigation menus, the property you describe is very important,
> even
> >> > when the difference between the natural sizes of the items is not
> >> > enormous.
> >
> > I'm OK with navigation menus having to add min-width: min-content to
> avoid
> > overflow (or using flex: auto).  Basically, you're opting into the slow
> > layout, but a navigation menu is simple and the slower layout is OK.
> >
> > The benefit is when trying to use flexbox for site layout (like 3
> column),
> > you get fast behavior by default.  Having to compute the min-content
> size of
> > the main body is going to be slow.
>
> That's true. :/