Given a <div> containing <spans>, and given the CSS fragment div > span { border: 1px solid blue; margin: -1px; } when zoomed to some level other than an integer multiple of 100% (200%, 300%) the width of the border does not appear to equal the width of the margin. Specifically, in Chrome 48 (current Chrome beta at time of writing), at 110% zoom, the computed border-width is shown in devtools as 0.909px, as if the browser has divided out the zoom level from the border. The computed border width continues to decrease until 200% zoom, at which point it reports 1px again. It's not clear to me whether this is a Chromium issue or a WebKit issue (I'm not familiar enough with either to know where one ends and the other begins), so I apologize if I'm barking up the wrong tree. I see this same behavior in both Safari (El Capitan) and Firefox, though Firefox reports 1px as the computed value regardless of zoom level. I assume the intent here is to avoid non-integer border width for a solid border, but it breaks my layout and results in layouts that are in conflict with my (albeit naive) knowledge of the CSS box model. Thanks for your time. I did try to find duplicates, but nothing I saw addressed this specifically--apologies if I missed one. Cheers, --Ben Mosher
Does this reproduce in Safari?
Created attachment 267115 [details] Reproduces issue Zooming in between 100% and 200%, note that the border boxes in the abs-positioned "overlay" div are not exactly around the front layer's spans. Note: this actually works as expected on Safari 9. I will need to revisit my full example and see what's different. I did attempt to reproduce with the original (non-toy) application and it seemed to be broken as it is in Chrome (48) and Firefox (39).
Now that I take a second look at Safari, it does seem to scale border-width at the same rate as the margin, resulting in a correct layout. Sorry about that. Does that imply it's a Chromium issue, then?
It does! Please report in the Blink bug tracker.