Chrome Version: 72.0.3595.2 (Official Build) dev (64-bit)
OS: Ubuntu 18.10

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)


Chrome 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 Chrome.

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 Chrome.)
 

Deleted: test-keywords.html 591 bytes

test-keywords.html 591 bytes View Download