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

Thanks for updating the spec. That makes things clearer/make more
sense. However, I have a couple of concerns:

- I believe as worded right now, the text does cause a division by
zero in case the flex grow factor is 0, as the minimum of 1 is now
removed

- I haven't traced the algorithm but just wanted to make sure that you
took into the account flex factors that sum to less than one (e.g.
flex: 0.8 + flex: 0.9)

- I sort of wish the spec was more explicit that vertical sizing of a
flex container is different from all other display types in that it
follows the intrinsic sizing rules

- Most importantly, I feel like it's way too late to change the 0%
back to 0 for the flex basis. Flexbox has been shipping in browsers
for years. This does change what I think is a fairly basic property
for the flexbox algorithm.

- On a similar note, has the CSSWG made any attempts to see how
compatible the intrinsic size changes are, especially for column
flexboxes?

thanks,
-christian

On Sun, Aug 23, 2015 at 7:18 AM, fantasai <fantasai.lists@inkedblade.net> wrote:
> On 08/21/2015 12:20 AM, fantasai wrote:
>>
>>
>>>    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. :)
>
>
> Okay, I've checked in these changes, as they're really just bugfixes
> against errors in this section.
>
>> 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.
>
>
> This is still up in the air.
>
> ~fantasai
>

Received on Tuesday, 25 August 2015 01:43:27 UTC