I just realized that the text decoration skipping also skips parts within characters, which may look odd in some cases.

Example: https://jsfiddle.net/SebastianZ/qprzf15b/ as an example

Is it possible to continue drawing the line within the characters? Or is that intended for some reason?

Sebastian

Here's how I'd expect the line-skipping to look like.

Sebastian

I tend to agree this would be nice, but it's not currently supported by the underlying Skia feature we (and webkit and blink) are using to implement skip-ink. You'll see similar behavior in the other browsers. (It may be harder to demonstrate in browsers that don't yet support text-underline-offset, but you can try it with a default underline in typical fonts using letters like Д.)

I already assumed that it's a limitation of Skia. So I guess it would make sense to file an issue against their issue tracker? Looking at the patch of bug 1411922 I guess it's related to SkTextBlob::getIntercepts() not returning those intercepts, but I really don't have any knowledge of the underlying APIs. So I would really appreciate if you or Charlie could file that issue there.

Sebastian

I'm not convinced that underlining inside glyphs would be an improvement in legibility or aesthetics in the general case.
The spec discusses this and explicitly states that it's not mandating any normative behavior.
https://drafts.csswg.org/css-text-decor-3/#line-decoration
In their "goal" example, I definitely prefer the rendering on the 2nd line ("g" without decoration inside the descender). It looks better and it's more readable IMO.

Shaping the line-endings to follow the glyph seems like it would be an improvement though.

Fwiw, it appears WebKit tried this but decided it was "too ugly to ship":
https://github.com/w3c/csswg-drafts/issues/4493#issuecomment-551257774

I agree that underlining inside glyphs may not always be beneficial for readability, though at least in some cases I believe it is. I've filed a specification issue to discuss this more generally first.

Sebastian