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

On 23/05/2012 16:32, Tab Atkins Jr. wrote:
> 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.)

Hmm, good point.  It looks like this particular use case doesn't provide 
anything useful when choosing the initial value.

> 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.

I agree; the overflow situation seems to be handled better now.

I think the 'auto' behaviour described above is a more natural and 
friendly default in general, in agreement with fantasai's earlier 
comment (and Alex's later one), but you've convinced me that horizontal 
menus aren't a compelling use case for deciding this because they often 
won't want to use flex (merely the alignment properties).

Cheers,
Anton Prowse
http://dev.moonhenge.net

Received on Wednesday, 30 May 2012 08:23:34 UTC