Chrome's intrinsic inline-size calculations don't account for whitespace before empty child with nonzero margins (which causes unnecessary wrapping in intrinsically-sized element)
Reported by
kdub...@mozilla.com,
Feb 22 2018
|
|||||
Issue descriptionChrome Version: Version 66.0.3350.0 (Official Build) canary (64-bit) OS: macOS 10.13.3 (17D47) What steps will reproduce the problem? (1) Go to https://www.pistonheads.com/classifieds?Category=motorbikes&M=0&Option=1&ResultsPerPage=15 (2) "Classified > Motorbikes" seems normal (3) It has a margin-bottom: -0.5em; .breadcrumb ul li { float: left; margin-top: 0.8em; margin-bottom: -0.5em; } The margin-bottom here is to compensate this rule .breadcrumb ul li::after { content: ">"; margin: 0.5em; } Analysis of Daniel Holbert: https://webcompat.com/issues/15566#issuecomment-367549709 ========= One problem with this, though -- this positive margin is actually in the horizontal axis. margin: 0 0.5em; sets margin-top/bottom to 0, and margin-left/right to 0.5em. So it doesn't actually cancel out in the way that it seems like they might be intending it to. But in Chrome, it does seem to trigger a linewrap after the final element (with an empty box with nonzero height wrapping to the next line). And I think that's a Chrome bug, actually. Anyway -- that's why in Chrome, they do need "margin:-0.5em" to cancel out that extra linewrap height. =========== The full bug report is at https://webcompat.com/issues/15566 What is the expected result? What happens instead? Please use labels and text to provide additional information. For graphics-related bugs, please copy/paste the contents of the about:gpu page at the end of this report. It creates a webcompat issue with Firefox in this case.
,
Feb 22 2018
Reduced testcase: https://jsfiddle.net/sjap2xxw/ STR: Load that ^ testcase EXPECTED RESULTS: No space between "aaa" and its bottom border. ACTUAL RESULTS: There's a blank line between "aaa" and its bottom border. (If you open devtools inspector, you can see that it's the empty span which has been wrapped to a second line.) Compare to the second "bbb" example in the testcase (which does not wrap) -- it only differs from the first example in that we've added some text inside the span. This seems to be an issue with measuring intrinsic sizes. Chrome is incorrectly disregarding the (nonzero) width of the empty span's margin-box when it computes the intrinsic size of the .container element.
,
Feb 22 2018
Firefox 60 and Edge 16 produce "EXPECTED RESULTS" on that testcase, BTW. Chrome 66 and Safari 11 produce "ACTUAL RESULTS".
,
Feb 22 2018
Filed a WebKit/Safari version of this bug, too: https://bugs.webkit.org/show_bug.cgi?id=183029
,
Feb 22 2018
Actually, sorry -- Safari and Chrome *do* account for the margins! The thing they're not accounting for is the *whitespace character* just before the empty element. Here's a testcase that demonstrates that (comparing an inline-block *with* whitespace before an empty element with a margin, vs. an inline-block *without* that whitespace character): https://jsfiddle.net/u1Lbz9oz/
,
Feb 22 2018
,
Feb 22 2018
Also, it turns out Safari seems to behave a bit different here, too. They actually match Firefox & Edge on the testcases I linked here (despite what I said above -- I wasn't retesting them as often as I should've). But Safari and Chrome do both fail (linewrap unnecessarily inside the black box) on this third testcase: https://jsfiddle.net/xwxsfLpv/
,
Feb 22 2018
Thanks for the detailed report and test minimal case.
,
Feb 27 2018
|
|||||
►
Sign in to add a comment |
|||||
Comment 1 by dholb...@gmail.com
, Feb 22 2018