[Webkit-unassigned] [Bug 191390] New: "min-content" & "max-content" keywords should behave as initial value in block axis (but WebKit improperly treats them as the content-size)

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=191390

            Bug ID: 191390
           Summary: "min-content" & "max-content" keywords should behave
                    as initial value in block axis (but WebKit improperly
                    treats them as the content-size)
           Product: WebKit
           Version: Safari 12
          Hardware: Unspecified
                OS: Unspecified
            Status: NEW
          Severity: Normal
          Priority: P2
         Component: Layout and Rendering
          Assignee: webkit-unassigned at lists.webkit.org
          Reporter: dholbert at mozilla.com
                CC: bfulgham at webkit.org, simon.fraser at apple.com,
                    zalan at apple.com

Created attachment 354122

  --> https://bugs.webkit.org/attachment.cgi?id=354122&action=review

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.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20181107/3d70a993/attachment.html>