1728453 - text-underline-offset doesn't looks correct on Sirius XM page

Status: RESOLVED INVALID

(Core :: Layout: Text and Fonts, defect)

Description

[Mike Kaply [:mkaply]]

Attachment: Comparison of Firefox and Edge

On this page:

https://www.siriusxm.com/channels?package=SXM_SIR_AUD_PKG_MM

The underline appears wrong on Firefox, but correct on Edge/Chrome.,

Narrowed down test case is:

data:text/html,<span style="text-underline-offset: 0; text-decoration: underline; text-decoration-thickness: 1px; ">Underlined</span>

See attached image.

Comment 1

[Jonathan Kew [:jfkthame]]

It's Blink that has incorrect behavior here. This is a known bug: see https://bugs.chromium.org/p/chromium/issues/detail?id=1172623.

The spec says that when text-underline-position is auto (the initial value, as here), the zero position from which text-underline-offset is measured is the alphabetic baseline. So text-underline-offset: 0 puts the line exactly at the baseline, which means it touches the glyphs, and (unless text-decoration-skip-ink: none is used), it'll be interrupted wherever the glyph ink occurs.

I don't really know why the site is messing with text-underline-offset here at all, but adding text-underline-position: from-font would probably get them closer to what they wanted. But given this CSS, Gecko's behavior is exactly per spec, and Blink is wrong.

Note that in Safari, too, the underline appears exactly at the baseline of the text. (It doesn't have the skip-ink gaps, but that's because the site also uses the non-standard -webkit-text-decoration-skip: objects to override this; removing that results in Firefox-like rendering.)

Comment 2

[Mike Kaply [:mkaply]]

I wonder if they're going to fix it? Or not knowing it breaks websites?

I've opened a webcompat bug.