Blink mistakenly adds "margin-top" to intrinsic *width* calculation for floats |
||
Issue descriptionChrome Version: 65.0.3325.31 (Official Build) dev (64-bit) OS: Ubuntu 17.10 What steps will reproduce the problem? (1) Visit https://jsfiddle.net/5rwq3m0o/ What is the expected result? Each teal div should have the same width. What happens instead? Each teal div is wider than the last. Please use labels and text to provide additional information. The only difference between the divs are "margin-top" values on their children. Apparently Chrome is mistakenly factoring this vertical margin into the width calculation, when accounting for the writing-mode difference between parent & child. Note: - Edge 16 gives "Expected results", with the teal divs all being just wide enough to fit the text. - Firefox Nightly 60 gives a less pretty version of "expected results", with the divs all being 4px wide (not doing layout on the text -- only wide enough for the borders) - Safari 11 and Chrome give the results that I'm reporting as buggy here, with the divs being wider if there's a larger 'margin-top' value on the child.
,
Feb 8 2018
Thank you for the report!
,
Mar 6 2018
This affects other shrink-to-fit width code scenarios. I can create an absolute position version of Daniel's test and/or a float version of Daniel's test and the wrapping (teal) div will become wider than it should be. It is very possible that there is an equivalent absolute position version of Daniel's test in the list of failed tests listed in Issue 505151.
,
Mar 6 2018
A quick test to illustrate what I meant: http://www.gtalbot.org/BrowserBugsSection/CSS3WritingModes/Issue810231-margin-top-added-to-width-001.html |
||
►
Sign in to add a comment |
||
Comment 1 by dholb...@gmail.com
, Feb 8 2018