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

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

From: Ojan Vafai <ojan@chromium.org>
Date: Mon, 4 Jun 2012 10:05:20 -0700
Message-ID: <CANMdWTuSp7xOQy3g8WKiZveGXCZCx9vwEz_+XmvQOb7ZdaMJTw@mail.gmail.com>
To: fantasai <fantasai.lists@inkedblade.net>
Cc: www-style@w3.org
On Wed, May 30, 2012 at 10:57 PM, fantasai <fantasai.lists@inkedblade.net>wrote:

> On 05/30/2012 05:25 PM, Ojan Vafai wrote:
>
>> Alex, I see what you're saying now. I was wrong about the performance
>> impact for row. The performance impact of
>> flex-basis:auto *only* applies to column. You need to layout once to get
>> the flex item's height, then flex the height, then
>> layout again for any descendants of the flex item that depend on the
>> height (e.g. % heights). It's true that the second layout
>> can be cheaper than the first for most cases if you do the right
>> optimizations, but there are legitimate cases where it would
>> be expensive.
>>
>> In a world where you flex by default, I suppose flex-basis:auto is
>> sensible. However, we believe that "flex:0 0 auto" is
>> simply what web developers will want and expect for nearly all cases
>> because there will be only a single flexing item in the
>> flexbox. In the old scheme of defaulting "flex: 0 0 auto", most UIs would
>> only need to set "flex: 1" on a single item and not
>> need to set flex on any other items.
>>
>> Also, flex-basis:auto is hard to wrap your head around. That was my
>> experience as a web developer writing pages towards the
>> old flexbox API and that has been my experience writing test cases for
>> the new flexbox API. flex-basis:auto consistently led
>> to surprising layouts.
>>
>> That all said, we're willing to concede here:
>> 1. The performance isn't as bad as we initially thought, although there
>> are still cases where it's quite a bit worse.
>> 2. fantasai's original comment that most people will just set "flex:none"
>> or "flex:1" on all the children anyways is
>> compelling (i.e. people will effectively get flex-basis:0 because that's
>> what the majority of UIs will want).  However, it
>> seems silly to require the majority of pages using flexbox to set
>> "flex:none" on every flex item when all they want is "flex:
>> 0 0 auto" for all items except the one item that will flex.
>>
>
> Ok, I'm glad we're in agreement that flex-basis initial value can be
> 'auto'. :)
> So now the issue you're raising is, why is default flexibility 1 instead
> of zero.
> We brought up this change because of a few reasons:
>
>  * Most importantly, having negative flexibility on by default prevents
> overflow
>    in cases where it's not necessary. (Authors don't think about narrow
> screens;
>    with min-content as the default minimum and Alex's new sensible
> formulation
>    for negative flexibility, turning it on by default is better for users.)
>
>  * Secondly, the cross-axis defaults to 'stretch', and turning on positive
> flex
>    is the main-axis equivalent of that, so making it 1 by default matches
> that
>    behavior. A single flex item in a flexbox will by default fill the
> flexbox
>    in both dimensions.
>
>  * It's called Flexbox. Seems reasonable for the items to flex by default.
> :)
>
> To me, the first item is the most important. I want to avoid overflow,
> because
> it makes the page hard or impossible to read. But I also understand your
> concerns
> about making Flexbox easy to use. No flexibility by default works better
> with the
> other features of flexbox, such as alignment and auto margins, or to have
> one item
> that takes up all the space.
>
> But actually, you only need to turn off positive flexibility to get those
> use
> cases, so a third option is to have 'flex: 0 1 auto' be the initial values.
> This would solve your usability concerns for the author, and it would
> solve my
> readability concern for the user. It's only real disadvantage is that it's
> inconsistent with cross-axis 'stretch'.
>
> So to summarize, the possibilities are:
>
>  Proposal A: ''flex: none'' (discarded at Hamburg)
>     * It's easier to use alignment and auto margins
>     * Easier for use cases that want some but not most items flexible,
>       e.g. one item takes up all free space
>     - Doesn't have negative flexibility be default, which could help
>       prevent overflow in many cases
>     - Inconsistent with 'stretch' default in cross-dimension
>
>  Proposal B: ''flex: auto'' (adopted at Hamburg)
>     + Negative flex is on by default, preventing overflow in many cases
>     + Consistent with 'stretch' default in cross-dimension
>     - Harder to use alignment and margins, since have to turn off flex
> first
>     - More work for use cases that want most items inflexible
>
>  Proposal C: ''flex: 0 1 auto'' (proposed here)
>     + Negative flex is on by default, preventing overflow in many cases
>     + Easy to use alignment and auto margins since positive free space is
> not flexed
>     + Easy for use cases where free space is distributed to e.g. only one
> item
>     - Inconsistent with 'stretch' default in cross-dimension
>
> I'm happy with either A or C. Now it's a question of what everyone else
> thinks. :)
> I've loaded this discussion into the wiki at
>  https://wiki.csswg.org/topics/**flex-initial-value<https://wiki.csswg.org/topics/flex-initial-value>


My preference would obviously be for C. I agree that strikes the best
balance of making the API easy to use while doing something useful by
default. Avoiding overflow is a nice benefit of negative flexing by default.

Sorry for not responding sooner. There were some mail delivery issues. No
www-style email from 5/30 onward hit my inbox until this weekend.
Received on Monday, 4 June 2012 17:13:19 GMT

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