RE: [css-flexbox] Intrinsic Cross Size Definition Totally Wrong

>>> Side note: current browsers also set the *flex container’s* inner
>>> size to that largest value, which is clearly wrong, as it is
>>> guaranteed to cause overflow if there are multiple lines. We would
>>> need to require the cross-size to be the sum of the line’s cross
>>> sizes after doing item layout and linebreaking as outlined above.
>>
>>
>> Note: IE does the correct behavior, wrapping the flex container around
>> all of the columns. Edge preserves this behavior for max-content.
>>
>> It would be nice if implementations can align on intrinsic sizes of
>> flex containers not causing their content to overflow. :) :) :)
>
>Right, I somehow didn't think about this correctly, totally missing the fact that
>the correct behavior requires doing layout in order to compute the preferred
>width.
>
>On behalf of Blink, I want to object to requiring any behavior that requires
>layout in order to calculate the preferred width of a container. So, I guess
>there's no good solution here :(
>
>-Christian

We continue to stand by[1] that the heuristics used by Gecko/Blink/Webkit in shrink-to-fit contexts are not intuitive for authors, this thread being a good example of this. Additionally, we continue to want other vendors to do the architectural work necessary to provide both a performant implementation without compromising a good solution. Here is a good example of this: http://jsfiddle.net/xzt063uv/2/ - just because I placed the content inside of a container that is shrink-to-fit; we believe it should not force the content to change how it lays out when there is enough space within the viewport to match the exact same layout in a non shrink-to-fit container.

To be blunt, if your solution to this is, "the flex container will shrink down around the first column or the first item", that is not something that we can get behind as that is not a viable solution and you're basically providing a broken flex implementation.

Greg

[1] http://logs.csswg.org/irc.w3.org/css/2014-10-27/#e484693

Received on Monday, 14 December 2015 18:31:51 UTC