Bug 182595 - WebKit mistakenly adds "margin-top" to intrinsic *width* calculation for floats
Summary: WebKit mistakenly adds "margin-top" to intrinsic *width* calculation for floats
Status: NEW
Alias: None
Product: WebKit
Classification: Unclassified
Component: Layout and Rendering (show other bugs)
Version: Safari 11
Hardware: Unspecified macOS 10.13
: P2 Normal
Assignee: Nobody
URL:
Keywords: InRadar
Depends on:
Blocks:
 
Reported: 2018-02-07 19:18 PST by Daniel Holbert
Modified: 2018-03-06 11:12 PST (History)
5 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Daniel Holbert 2018-02-07 19:18:46 PST
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 WebKit 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.

Chrome version of this bug:
https://bugs.chromium.org/p/chromium/issues/detail?id=810231
Comment 1 Radar WebKit Bug Importer 2018-02-08 16:38:11 PST
<rdar://problem/37371418>
Comment 2 Gérard Talbot 2018-03-06 11:12:52 PST
Test on other shrink-to-fit width code scenarios:

http://www.gtalbot.org/BrowserBugsSection/CSS3WritingModes/Issue810231-margin-top-added-to-width-001.html