Floats with negative margins behaving non-interoperably in Firefox and Chrome
Categories
(Core :: Layout: Floats, defect, P2)
Tracking
()
Tracking | Status | |
---|---|---|
firefox66 | --- | affected |
People
(Reporter: twisniewski, Unassigned)
Details
(Whiteboard: [webcompat])
Attachments
(1 file)
515 bytes,
text/html
|
Details |
In the attached test-case, it seems that Chrome is pushing the <ul> under the <span>, while Firefox is not. It almost seems as though Firefox sees the negative right-margin, and thinks it can still fit the <ul> on the same line as the <span> somehow.
![]() |
||
Comment 1•7 years ago
|
||
Strange. For both Chrome and Firefox the <ul> suddenly disappears at a given margin-right percentage value, but for Chrome that seems to happen when the value is the value at which it dissapears in Firefox + 100%. For example, for me when the browser is maximized, the <ul> disappears at 19%, but in Chrome it disappears at 119%. At half screen width it disappears in Firefox at 29%, but in Chrome at 129%.
Updated•6 years ago
|
Comment 2•6 years ago
|
||
I believe this is the same as bug 1400958 -- we do weird things when the float has a negative overall margin-box size.
Comment 3•6 years ago
|
||
Moving see-also and webcompat? flag to dupe target.
Updated•6 years ago
|
![]() |
||
Updated•6 years ago
|
Reporter | ||
Comment 4•6 years ago
|
||
Moving see-also flag to dupe target.
Comment 5•4 years ago
|
||
Update: per my note in the dupe-target (bug 1400958 comment 11), it seems Chrome changed their behavior here, and they match our rendering of the attached testcase now (ever since Chrome 76).
Comment 7•3 years ago
|
||
Undoing my dupe-target-bump; this is in fact a dupe of bug 1400958, and Chrome changed their behavior to match us in the attached testcase, which means we're probably fine keeping our current behavior.
(The patch in bug 1745310 changes our behavior in some similar scenarios but not in this particular scenario.)
Description
•