Same CSS-height is not even in render when zoom
Reported by
zcyzcy88...@gmail.com,
May 23 2017
|
||||||||||||
Issue descriptionUserAgent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:53.0) Gecko/20100101 Firefox/53.0 Steps to reproduce the problem: This is about horizontal line (border-top, border-bottom, short height, long width), vertical line (border-left, border-right, long height, short width) is also. Zoom in decimal rate, such as 150% What is the expected behavior? border: https://jsfiddle.net/0grpu7g2/4/ border is even. What went wrong? height: https://jsfiddle.net/naLs3r5q/2/ height is not even. This must be a pixel-grid-snap problem when zoom. Did this work before? No Chrome version: 60.0.3108.0 Channel: canary OS Version: 10.0 Flash Version: A affected demo: Google Docs Look the dividing line.
,
May 24 2017
Able to reproduce the similar behavior on Firefox and on the latest chrome canary(60.0.3109.0) and older chrome version(30.0.1549.0) as well. This is replicated on Windows-10, Mac OS 10.12.4 and Linux Ubuntu 14.04. Marking this as Untriaged for more inputs on correct behavior here.
,
May 24 2017
Another exmaple: Chrome DevTools Look the lines, so ugly and annoying :(
,
May 24 2017
,
May 25 2017
As updated in C#2, This is non regression issue and seeing similar behavior on older chrome version: 30.0.1549.0 across all OS. Tested with https://jsfiddle.net/naLs3r5q/2/ zooming to 150%.
,
May 26 2017
This is ugly, but edge renders the same way too - we have interop on the current behavior. Forwarding to tabatkins@ to take a closer look and comment on specification implications
,
May 26 2017
Not a direct spec issue - per spec, everything's infinite-precision, but with a UA-specified rounding that we don't concern ourselves with. The difference in rendering is because all browsers go to great pains to make sure that borders all snap in the same direction, because people *hate* when their same-size-in-CSS borders end up different widths on screen. On the other hand, we're all generally okay with other sizes snapping differently; in some cases it's *required* to get the rendering people want, like splitting 1000px of width between seven menu options all specified with "width: calc(100% / 7);" - if they all snap to the same integer px you'll either underflow or overflow the container, so instead browsers all do intelligent rounding that makes them add up to exactly 1000px. This does end up having undesirable effects in places like this, where the rounding becomes obvious. It's not zoom-based at all; you can reproduce it exactly by using a border/height of 1.2px or something - all the borders will be consistent, but the heights will vary slightly between the children. All in all this is a quality-of-implementation issue. Nothing is broken, per se, but we can still try and do something about this if we want. It's just going to run headlong into some thorny issues that already exist.
,
May 29 2017
,
May 29 2017
,
May 30 2017
This really is WontFix. We have to put the discretization somewhere, and there are not really better places to put it.
,
Jun 9 2017
I know it is hard to fix. But at least you should try to do something, such as individual handle 1px height. A lot of website use 1px height (not 1px border-top) <hr>. |
||||||||||||
►
Sign in to add a comment |
||||||||||||
Comment 1 by ajha@chromium.org
, May 24 2017