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

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.

-christian

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