997424 - Zooming in breaks alignment of borders

Status: RESOLVED INVALID

(Core :: Layout, defect)

Description

[Elbart]

Attachment: zoom_13_16.htm

Open the testcase and zoom in with Ctrl+MousewheelUp four times.
It should look something like this:
http://i.imgur.com/nB72kV0.png

The boxes in at least the 16px-rows are supposed to be aligned neatly, like the 20px rows. The 13px-rows might be off because of the image being 15px*15px.

Also happening with HWA off.


Also of interest:
The "offset" of the boxes apparently depends on where they are in the code.

I.e. the upper 16px-row has no offset, whereas the lower 16px-row has an offset of 1px.
For the 13px-rows it's the other way around: Bigger offset at the top.


// Discovered during researching bug 997384

Comment 1

[Daniel Holbert [:dholbert]]

It looks like what's happening in all of the misalignment cases (including 13px) is, the <img> is aligning its baseline (15px from the top) with the baseline of the text alongside it (which is slightly less than 15px from the top -- but that "slightly less" is only exposed at higher zoom levels).

I'm not sure the browser's actually doing anything wrong here.

Note that the problem goes away (in all cases, including the 13px cases) if you add style="vertical-align: top" to the <img> elements.

Comment 2

[Daniel Holbert [:dholbert]]

Put another way: A sub-pixel positioning difference (which gets rounded down to 0 at the default zoom-level) is just getting magnified when you zoom in. I think that's expected.

Comment 3

[Daniel Holbert [:dholbert]]

Resolving as INVALID, since I don't think this is a bug, per comment 2 (with more details in Comment 1).

FWIW, note also that Chrome matches our rendering (no visible offset for 16px at default zoom level, w/ offset becoming visible at higher zoom levels).

Comment 4

[Elbart]

(In reply to Daniel Holbert [:dholbert] from comment #2)
> Put another way: A sub-pixel positioning difference (which gets rounded down
> to 0 at the default zoom-level) is just getting magnified when you zoom in.
> I think that's expected.

In another bug I read that the support for hidpi-monitors is basically done via zooming. Won't layout-issues like this one become more obvious to hidpi-users in the future?


Also: Chrome can hardly be the benchmark, as it shows the same issues when zooming into the URL and focusing on the pagination at the top right. IE11 doesn't show the same "rounding errors".

(You need to disable HWA on Windows-Firefox to get rid of the HWA-related alignment-issues and do a fair comparison.)

Comment 5

[Daniel Holbert [:dholbert]]

(In reply to Elbart from comment #4)
> In another bug I read that the support for hidpi-monitors is basically done
> via zooming. Won't layout-issues like this one become more obvious to
> hidpi-users in the future?

Sure. Any layout issue that involves something being mispositioned by a fractional pixel will be more visible when zoomed in or on a high DPI monitor.

> Also: Chrome can hardly be the benchmark, as it shows the same issues when
> zooming into the URL and focusing on the pagination at the top right.

(I wasn't using it as a "benchmark". I just mentioned it for comparison.)

> IE11 doesn't show the same "rounding errors".

It does for me, on the testcase you attached, though I had to tweak the font size from 16px to 16.2px in order to trigger the discontinuity from 100% zoomlevel (borders aligned) to higher zoomlevels (not aligned), on both Firefox & IE on Windows.

Comment 6

[Daniel Holbert [:dholbert]]

Note: At the testcase you attached, I can fix the alignment issues by adding the following styles in the "Stylish" addon:
 form  img {
    vertical-align: top;
 }

 .pagination span.first_last a,
 .pagination span.prev_next a {
     position: static !important;
 }

The first rule is an actual fix for this bug (as noted in comment 1).

The second rule it to disable some strange "position: relative: top: -2" rules that the site applies, probably as an attempted hackaround for this bug.

Comment 7

[Daniel Holbert [:dholbert]]

(In reply to Daniel Holbert [:dholbert] from comment #6)
> Note: At the testcase you attached

Sorry, I meant "at the URL you posted"
 ( http://forum.vbulletin-germany.com/showthread.php/27501/page3 )

Comment 8

[Daniel Holbert [:dholbert]]

(The point of comment 6 [and comment 7] is: the site is unintentionally relying on baseline-alignment of images with text, and the influence that has on the size of the image+text's container, and the influence *that* has on the relative vertical positioning of several containers.

The site are attempting to hack around it with a hardcoded "position: relative" positioning rule. This 'fix' is unreliable unless they know the exact font metrics (which they can't really predict, cross-platform, and which aren't guaranteed to place the text baseline at an exact pixel value).

A more robust way for them to address this is by turning off the baseline-alignment of these images.)

[note: perhaps replace "the site" with "the forum software", as appropriate]