Bug 191390 – "min-content" & "max-content" keywords should behave as initial value in block axis (but WebKit improperly treats them as the content-size)

• Status: RESOLVED
• Resolution: FIXED
• Component: Layout and Rendering

[Daniel Holbert]

Created attachment 354122 [details]
testcase 1

I'm testing using Safari 12 on Mojave.


What steps will reproduce the problem?
(1) Load attached testcase, or visit https://jsfiddle.net/s9bw6j4c/

What is the expected result?
 No red should be visible. (i.e. the black-bordered areas should all be 0-height)

What happens instead?
In the first two chunks, there is a large rectangle visible (i.e. the black bordered area expands *beyond* its specified "height:0px" to encompass its child's height)


WebKit is improperly honoring "min-height: min-content"/"max-content" here -- if you remove that line, the rendering switches to the correct rendering, as shown in the third chunk of this testcase.

The css-sizing-3 spec says that min-content and max-content only resolve to the content size in the inline axis, and "otherwise behaves as the property’s initial value".  So in this case, it should behave as if it weren't specified, but that's not what happens in WebKit.

Spec link:
https://drafts.csswg.org/css-sizing-3/#valdef-width-min-content

Firefox 64 beta & 65 Nightly (which support these prefixed keywords in the block dimension) gives the expected behavior.

(Edge and earlier Firefox versions give the expected behavior, too, but only because they don't support these keywords -- not in the block dimension at least, for older Firefox versions.)

Note: I ran into a version of this causing a compatibility issue on Facebook.com -- see https://github.com/webcompat/web-bugs/issues/21006 for details. (That case has to do with the "min-height:auto" special case on flex items with overflow:hidden, where it resolves to 0.   Facebook is naiively trying to opt out of that special case by specifying "min-height:max-content", but per spec, that should behave like the initial value and so should still resolve to 0. But it doesn't in WebKit.)

Chrome has the same bug -- I filed https://bugs.chromium.org/p/chromium/issues/detail?id=902863 on this for Chrome.

[Michael Puckett]

This is still present in Safari 13.

The Chrome issue has been fixed.

This is a cross-browser inconsistency for me during development. Animating max-height from max-content to 0 greatly simplifies transitions, but this is not possible in Safari.

[Rob Buis]

Created attachment 420939 [details]
Patch

[Rob Buis]

Created attachment 420960 [details]
Patch

[Darin Adler]

Comment on attachment 420960 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=420960&action=review

> LayoutTests/ChangeLog:11
> +        Remove test that makes now incorrect assumptions.
> +
> +        * fast/css-intrinsic-dimensions/height-expected.html: Removed.
> +        * fast/css-intrinsic-dimensions/height.html: Removed.

It’s great to remove tests based on incorrect assumptions. This doesn’t explain why it’s OK to have reduced test *coverage*, though. Presumably the reason is either that WPT has thorough testing of this that was already redundant with this test, or that we have plenty of coverage elsewhere (but then I’d expect us to be updating expected results for the progression).

[Rob Buis]

Created attachment 421090 [details]
Patch

[EWS]

Committed r273206: <https://commits.webkit.org/r273206>

All reviewed patches have been landed. Closing bug and clearing flags on attachment 421090 [details].

[Radar WebKit Bug Importer]

<rdar://problem/74559442>