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

On 08/31/2015 05:23 PM, fantasai wrote:
> On 08/25/2015 03:42 AM, Christian Biesinger wrote:
>>
>> - 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.
>
> I think that the 0% change was a mistake that doesn't make sense in
> the context of a correct implementation of this section. I also it's
> unlikely that someone would use the flex: <integer> shorthand syntax
> in an auto-height container (which is where this change will make a
> difference), since it doesn't do anything more than the initial value.
>
>> - On a similar note, has the CSSWG made any attempts to see how
>> compatible the intrinsic size changes are, especially for column
>> flexboxes?
>
> No, I don't think we have. Wrt column flexboxes, I suspect it's unlikely
> to make a difference since there's no reason to use values other than
> the initial value unless you want different behavior than you're getting
> now.

Btw, here's a testcase that would change:
   http://software.hixie.ch/utilities/js/live-dom-viewer/?saved=3613
The requirements to trigger a change in behavior are
   a) auto-height column flexbox
   b) flex: <integer>; (flex: <integer> <integer>? <basis> stays unchanged!)
   c) Ratio of integers doesn't match ratio of max-content sizes.
      (Common case of this would be varying max-content, with all
       items as flex: 1.)

The change that would happen here is that the items which have
flex: 1, which right now are individually content-sized, would
be equally sized such that the smaller items grow to match the
size of the biggest one (so that they're all equal-height, and
all fit their contents). In this specific testcase, the first
item would grow to match the height of the second.

I think the behavior in this case was pretty broken (everything
fell to zero height) in earlier implementations. Plus the
declaration that triggers it (flex: <integer>) doesn't do anything
in current implementations -- the initial value gets you the
content-height behavior on its own. Based on that, I think we're
unlikely to have a content-dependency problem by reverting the 0%
change.

~fantasai

Received on Wednesday, 2 September 2015 17:40:05 UTC