W3C home > Mailing lists > Public > www-style@w3.org > August 2015

Re: [css-flexbox] max-content contribution not defined for flex items

From: Christian Biesinger <cbiesinger@google.com>
Date: Fri, 21 Aug 2015 17:32:30 -0400
Message-ID: <CAPTJ0XHrsomDiE6Nj9HM5E10fSz8P-efpaJXbunDcUQZxyw9uQ@mail.gmail.com>
To: fantasai <fantasai.lists@inkedblade.net>
Cc: "www-style@w3.org" <www-style@w3.org>
That seems largely reasonable to me, though I haven't worked through
all the details.

General thought: Since we generally use flex-basis instead of width
(/height) in Flexbox, we should do that also for the intrinsic sizing
computation. That is, "flex-direction: row; flex-basis: 50px; width:
auto;" should produce the same intrinsic main size as "flex-direction:
row; width: 50px;".

Also, I just added a counter to Chrome 46 to see how many websites
will be affected by this intrinsic size change, at least for logical
widths. Hopefully the results will be promising.


On Fri, Aug 21, 2015 at 3:20 AM, fantasai <fantasai.lists@inkedblade.net> wrote:
> On 07/28/2015 01:21 PM, fantasai wrote:
>> The spec currently defines the max-content contribution of a flex
>> item as its hypothetical base size. However, I don't think this
>> works correctly for flexible items with a definite flex base size.
>> In particular, notice
>>    # For each flex item, subtract its flex base size from its
>>    # max-content contribution size,
>> This calculation will end up at zero for items with "flex: 1",
>> when the intention was for it to tend up at the max-content size.
>> Proposed definition:
>>   | The max-content main-size contribution of a flex item is:
>>   |   * if the item is growable, max(max-content, flex base size)
>>   |   * otherwise, its flex base size
>>   | clamped by its min and max main size properties.
>> Together with the definition of the max-content size of flex containers
>> [1],
>> I think this will give the expected results (no unnecessary wrapping
>> of shrinkwrapped flexboxes, no unnecessary or unrequested extra space).
>>    https://drafts.csswg.org/css-flexbox-1/#intrinsic-sizes
> Okay, I went over this section with dholbert today, and we've
> concluded that the spec needs the following changes:
> 1. Define the min-content and max-content contributions of a
>    flex *item* to be its min/max-content size, clamped as
>    appropriate.
>    [ As aforementioned, the spec references their "hypothetical
>      base size", which returns the min/max-content sizes when
>      the flex basis is 'content', but doesn't give correct
>      results (returns zero) in the the "flex: 1" case. ]
> 2. Clamp the flex items' min/max-content size contributions
>    not just by the min/max-width/height properties, but also,
>    if the item is inflexible in any direction, by its flex
>    base size.
>    [ For example, a shrinkable but not-growable item should
>      have its contribution also be min()ed against its flex
>      base size, not just its max-width/height. ]
> 3. Don't floor the flex factor at 1.
>    [ This might be left over prose from before we had partial
>      flexes. ]
> 4. Change "flex: 1" to expand to "1 1 0" instead of "1 1 0%",
>    [ We used 0% because in intrinsic size calculations it
>      would fall back to 'auto', but this is a hack that
>        a) doesn't give great results in many cases
>        b) breaks given a correct implementation of flex
>           container intrinsic sizing per spec
>    ]
> 5. Make sure things are worded so we don't divide by zero. :)
> Some examples to work through are two flex items:
>   * min-content = 1em, max-content = 2em
>   * min-content = 1em, max-content = 4em
> with all combinations of:
>   * all items as flex: 1, flex: auto, or flex: 0.5
>   * min-content sizing or max-content sizing for the container
> (We did this and they all made sense.)
> The one thing up in the air is if the flex base size should
> be considered a desired size, and therefore factored into
> the intrinsic size calculation. dholbert was leaning towards
> no, and considering the flex base size only as a starting
> point for flexing. The original proposal in this thread would
> do that:
>  | The max-content main-size contribution of a flex item is:
>  |   * if the item is growable, max(max-content, flex base size)
>  |   * otherwise, its flex base size
>  | clamped by its min and max main size properties.
> by using the flex base size as a minimum for the items' intrinsic
> sizes.
> Alternatively we could do that only if 'flex-basis' is 'auto',
> i.e. honor the width/height property (the main size property)
> as a minimum if it happens to be used in the flex calculations
> (as the flex base size). [ Using width/height unconditionally
> yields nonsensical results, since it isn't otherwise factored
> into the flex sizing calculations. ]
> ~fantasai
Received on Friday, 21 August 2015 21:33:00 UTC

This archive was generated by hypermail 2.3.1 : Friday, 21 August 2015 21:33:01 UTC