1622279 - Underline too high compared to Chrome and Safari

Status: RESOLVED DUPLICATE of bug 1584348

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

Description

[Jeff Muizelaar [:jrmuizel]]

Attachment: Test case

It looks especially bad because of underline skip ink

Comment 1

[Jonathan Kew [:jfkthame]]

This is an authoring problem, and the only reason it looks OK in Chrome and Safari is that they do not follow the (long-standing) CSS spec.

The underline is being applied to the <a> element, so it is drawn slightly below the baseline of that inline box, according to the current font's underlinePosition property. So far, so good.

But then the actual text is wrapped in a <span> inside the <a>, and the inner <span> has vertical-align:middle applied. This shifts the text downwards by a couple of pixels.

The underline, however, was applied to the surrounding <a>. So now the shifted-down text crashes into it.

This doesn't occur in Chrome or Safari because they apply text-decoration lines separately to inline children of the decorated element. This is in direct violation of the spec, where there's even an illustrated example showing "Correct and incorrect rendering of <u>A^B<big>C</big>D</u>".

(I'm sure we have existing reports of this, probably resolved as INVALID; it comes up from time to time.)

See https://bugs.chromium.org/p/chromium/issues/detail?id=1008951 (there's also a relevant older Blink bug that I can't find offhand).

Comment 2

[Jeff Muizelaar [:jrmuizel]]

Would it make sense to change the spec to match Safari and Chrome's behaviour?

Comment 3

[Jonathan Kew [:jfkthame]]

No. Their behavior makes it near-impossible to present something like <u>Einstein says <i>e = mc<sup>2</sup></i></u> or <u>Don't confuse H<sub>2</sub>O with H<sub>2</sub>SO<sub>4</sub> or you'll be sorry!</u> or even just <u>Friday 13<sup>th</sup> March</u> in a reasonable way.

Comment 4

[Jeff Muizelaar [:jrmuizel]]

I filed a webkit bug: https://bugs.webkit.org/show_bug.cgi?id=209070

Comment 5

[Hiroyuki Ikezoe (:hiro)]

(In reply to Jonathan Kew (:jfkthame) from comment #1)

(I'm sure we have existing reports of this, probably resolved as INVALID; it comes up from time to time.)

Probably that's bug 1584348.

Comment 6

[Jeff Muizelaar [:jrmuizel]]

Chrome has fixed https://bugs.chromium.org/p/chromium/issues/detail?id=1008951 in 105 but their rendering still looks different then ours on the attached test case. Is there some other disagreement about the spec/implementations?

Comment 7

[Jonathan Kew [:jfkthame]]

If the very first piece of content within the underlined element has a shifted baseline, they appear to base the underline position on this. See:

data:text/html,<div style="font:99px serif"><u>foo</u> abc <u><span style="vertical-align:-.5ex">x</span>bar</u>

where the underlines of "foo" and "bar" ought to be positioned similarly, with the displaced child span in the second case having no effect on the position (as the decoration is applied to the <u> element, not the <span>). However, Chrome shifts the second underline down.

Note that this only happens if the shifted child is the first thing within the decorated element; if there's some text -- even just an invisible character -- before it, then it has no effect:

data:text/html,<div style="font:99px serif"><u>foo</u> abc <u>&shy;<span style="vertical-align:-.5ex">x</span>bar</u>

I think this is a bug in Chrome's implementation (though I suppose it could be a deliberate but IMO misguided implementation decision).

I'll file a bug and see what Koji has to say.

Comment 8

[Jonathan Kew [:jfkthame]]

Filed https://bugs.chromium.org/p/chromium/issues/detail?id=1366288