Negative right margin is not working the same way as negative bottom margin
Categories
(Core :: Layout, defect)
Tracking
()
People
(Reporter: dma_k, Unassigned)
References
(Depends on 1 open bug)
Details
Attachments
(4 files)
User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Firefox/91.0 Waterfox/91.5.0
Steps to reproduce:
The test scenario is the continuation of vertical tabs (https://jqueryui.com/tabs/#vertical) for JQuery UI. The attached HTML is my attempt to hide/overlap the right border of the selected tab. It is working perfectly for horizontal tabs (hiding the bottom border) using the technique when margin is negative for amount of pixels equal to border width and padding is positive for the same amount:
margin-right: -3px;
padding-right: 3px;
First screenshot is for this browser: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Firefox/91.0 Waterfox/91.5.0
Second screenshot is for this browser: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/97.0.4692.71 Safari/537.36
As one can see Chrome correctly renders the active tab which overlaps / hides the right border.
P.S. I failed to test with latest FF 96.0.3 as for attached HTML it complains:
"Layout was forced before the page was fully loaded. If stylesheets are not yet loaded this may cause a flash of unstyled content."
Comment 3•3 years ago
|
||
The Bugbug bot thinks this bug should belong to the 'Core::Layout' component, and is moving the bug to that component. Please revert this change in case you think the bot is wrong.
Comment 4•3 years ago
|
||
Part (at least) of the problem here is bug 1166120, which results in the layout being incorrect on initial reflow, and then changing when a re-layout is forced. To see this with the testcase, just hit Reload (resulting in an initial bad layout) and then zoom in and out (forcing re-layout and giving a different result).
It's possible there could be additional discrepancies related to the block-sizing of the orthogonal flow (which becomes its inline-size in the parent's writing mode) but the primary issue that needs to be fixed here is the layout instability. It could also be that the block-sizing issue for the vertical (sideways-lr) element is more to do with font- and line-spacing metrics, which are not necessarily consistent between browsers and platforms.
Indeed it has also to do with "sideways-lr" CSS property as without it the margin error is 1px so is present but is minimal.
Description
•