W3C home > Mailing lists > Public > www-style@w3.org > May 2012

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

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Wed, 23 May 2012 08:32:42 -0700
Message-ID: <CAAWBYDBEAjUhXc2SmmWEWqM01wKD2XeqwM=dh6_y7xT4VpNhHQ@mail.gmail.com>
To: Tony Chang <tony@chromium.org>
Cc: fantasai <fantasai.lists@inkedblade.net>, www-style@w3.org
On Tue, May 22, 2012 at 2:59 PM, Tony Chang <tony@chromium.org> wrote:
> I'm not able to come up with that many use cases where you would want auto.
>  For example, in a toolbar or menu, I would think you want all the buttons
> to be equally sized.  Using auto, you're not going to get that behavior
> unless your buttons are already equally sized.  Or if you want to do
> something like a 3 column layout (e.g., a flex ratio of 1-3-1), you would
> want the flex basis to be 0.  Can you provide some use cases where you would
> want a flex basis of auto?
>
> Auto sizing is very hard to predict the size of a flex item.  In practice, I
> think auto is only useful in a guess and check style of development where
> you try different flex basis values and see what looks good.

In my experience as a webdev, both behaviors have been requested for
nav bars - all buttons equal size and all items equally spaced. I
believe the desired behavior usually depends on whether the nav bar
looks like a subdivided rectangle or a collection of discrete items.
(However, I think the "equally spaced" case is actually most commonly
done with "flex:none; flex-pack:space;" or similar, so this isn't an
argument for default flex-basis to auto.)

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.


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.

Unfortunately, I wasn't thinking clearly when I wrote that.  Given the
min-width/height change we made in the spec, flex items won't shrink
below their min-content size.  Thus both 0 and auto have similarly
friendly behavior.  Here's an example:

<flexbox>
  <item>short</item>
  <item>loooooooooooong</item>
  <item>double double</item>
</flexbox>

If flex-basis is initially 'auto', then the items will shrink equally
until they reach their auto size.  If the flexbox gets any smaller,
the first two items aren't allowed to shrink any more, so the third
item will pick up the slack and line-break.  If the flexbox continues
to shrink, it'll eventually get below everyone's min-size, and will
start overflowing.

If flex-basis is 0, on the other hand, they all stay equal-size until
the flexbox becomes less than triple the size of the second item.
Then that item freezes, while the other two stay equal-sized, possibly
line-breaking the third item when it gets small enough.  Again, they
all stay fully visible until the flexbox is smaller than the sum of
their min-sizes.

Both of these behaviors seem quite reasonable, so it's not a good
basis to make a decision on.

~TJ
Received on Wednesday, 23 May 2012 15:33:34 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 17:20:54 GMT