1926453 - Button top border is missing, on zhihu.com (with "transform:scale(0.5)")

Status: NEW

(Web Compatibility :: Site Reports, defect, P3)

Description

[Daniel Holbert [:dholbert]]

(Spinning this off from bug 1896284 comment 10)

STR:

1. Visit https://www.zhihu.com/market/pub/119939174/manuscript/1283909748203241472
2. Look at the rounded-corner button near the top right, with text "查看详情" (which means 'view details')

ACTUAL RESULTS:
The top of the button is clipped, and the text looks a little bit lower than the vertical-centering position.

EXPECTED RESULTS:
No clipping, and maybe/probably the text should be vertically centered.

Screenshot showing the actual-results:
https://bug1896284.bmoattachments.org/attachment.cgi?id=9402653

This is unfortunately not easy to investigate on the site itself, since the site seems to have countermeasures to prevent DevTools from working, but I managed to get a reduced testcase from view-source, which I'll post shortly.

Comment 1

[Daniel Holbert [:dholbert]]

Attachment: testcase 1

Comment 2

[Daniel Holbert [:dholbert]]

This testcase has transform: scale(0.5); applied to this element, which seems to be the offending style here.

If I remove that, then our rendering gives EXPECTED RESULTS (and is obviously twice as large).

So the issue here is that
(a) The site's requested 0.5x scale is causing the border to disappear. This is tracked in bug 1775345. (or rather, bug 1258112 which that bug is duped against).
(b) That scale is maybe (?) also causing the text to snap to device-pixels in a way that biases downwards from what-a-user-would-perceive-as-the-vertically-centered-position.

Comment 3

[Daniel Holbert [:dholbert]]

Attachment: semi-reference case (twice as large because scale is removed)

Here's a sort-of reference case for testcase 1 -- I've removed the scale(0.5) so the content is larger as compared to testcase 1, but more importantly the actual-results issues seem to be gone. This demonstrates that the scale is what's causing the problem, as mentioned above.

Comment 4

[Daniel Holbert [:dholbert]]

Attachment: screenshot of testcase 1 in Firefox (left) vs Chrome (right)

Here's a screenshot from Firefox (left) and Chrome (right) on my Ubuntu 24.10 machine, placed side-by-side in my image editor for easy comparison.

Firefox's vertical centering actually looks at-least-as-good as Chrome's here; measuring from the extreme-most painted pixel in the glyph to the border, Firefox has a 1px difference between the spacing on top vs. bottom, whereas Chrome has a 2px difference.

So: I think the vertical centering here is probably fine, and the top-border is the real main issue here.

Comment 5

[Daniel Holbert [:dholbert]]

(and given that the border issue is bug 1258112, let's morph this bug here into a WebCompat site-report that's dependent on that underlying platform bug.)

Comment 6

[Tom25519]

This bug seems also happens on https://sourceforge.net/auth/

Comment 7

[Tom25519]

Attachment: sourceforge.net-Firefox.png

Comment 8

[Tom25519]

Attachment: sourceforge.net-Edge.png

Comment 9

[Daniel Holbert [:dholbert]]

(In reply to Tom25519 from comment #6)

This bug seems also happens on https://sourceforge.net/auth/

That's not this bug, and browsers basically agree on rendering there, so I don't think it's a browser bug at all. I see that issue in Firefox as well as Safari, and I also see it in Chrome if I manually add an outline style to the input elements there.

Any top outline there (including an outline triggered by focus state) will get clipped because sourceforge draws that textfield inside of a overflow: hidden; container, with the textfield right at the top edge. So any outline that gets added (outside the input element's border) will be above the top edge of that container and will necessarily get clipped. The only reason this doesn't happen in Chrome by default is that Chrome doesn't use an outline to indicate focus state; they seem to change the border color instead.