Here's another testcase, reduced from https://github.com/webcompat/web-bugs/issues/89019 , which is hitting the same root issue. The problem here (in both testcases) is that the site is assuming `margin: Npx` and `border: Npx` to occupy precisely the same amount of space. But in fact they aren't precisely the same size, because we snap borders to exact display-pixel boundaries to keep them precise. At bahn.de, the actual content has `margin-top: -2px` combined with `border: 2px`, and the site's logic precisely depends on those being exactly the same size. But in fact, we round the border down very slightly in order to snap it to exact display pixels, which means the negative `margin-top` causes the content to overlap with the preceding content. And due to how floats work, this turns out to cause the element to size to be 0 width, which bahn.de is not expecting. (Chrome agrees with us on this part, if I manually specify a slightly-more-negative `margin-top` to intentionally make the margin-top extend beyond the border). So the key thing here is just our difference in rounding behavior for borders.
Bug 1447447 Comment 2 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
Here's another testcase, reduced from https://github.com/webcompat/web-bugs/issues/89019 , which is hitting the same root issue. The problem here (in both testcases) is that the site is assuming `margin: Npx` and `border: Npx` will occupy precisely the same amount of space. But in fact they aren't precisely the same size, because we snap borders to exact display-pixel boundaries to keep them precise. At bahn.de, the actual content has `margin-top: -2px` combined with `border: 2px`, and the site's logic precisely depends on those being exactly the same size. But in fact, we round the border down very slightly in order to snap it to exact display pixels, which means the negative `margin-top` causes the content to overlap with the preceding content. And due to how floats work, this turns out to cause the element to size to be 0 width, which bahn.de is not expecting. (Chrome agrees with us on this part, if I manually specify a slightly-more-negative `margin-top` to intentionally make the margin-top extend beyond the border). So the key thing here is just our difference in rounding behavior for borders.
Here's another testcase, reduced from https://github.com/webcompat/web-bugs/issues/89019 , which is hitting the same root issue. The problem here (in both testcases) is that the site is assuming `margin: Npx` and `border: Npx` will occupy precisely the same amount of space. But in fact they aren't precisely the same size, because we snap borders to exact display-pixel boundaries to keep them precise. At bahn.de, the actual content has `margin-top: -2px` combined with `border: 2px`, and the site's logic precisely depends on those being exactly the same size. But in fact, we round the border down very slightly in order to snap it to exact display pixels, which means the negative `margin-top` causes the content to overlap with the preceding content. And due to how floats work, this turns out to cause the element to size itself to be 0 width, which bahn.de is not expecting. (Chrome agrees with us on this part, if I manually specify a slightly-more-negative `margin-top` to intentionally make the margin-top extend beyond the border). So the key thing here is just our difference in rounding behavior for borders.