Csswg-drafts: [css-text-4] Should text-decoration-thickness make text-decoration-skip-ink skip more empty space?

[jensimmons]

Currently, in both the Safari and Firefox implementations of Text Decoration 4, when an underline grows thicker, the amount of space that's skipped around each descender gets wider.

Like this:

Live demo: https://codepen.io/jensimmons/pen/xxxjEgd?editors=1100

As I've been teaching the new possibilities in underline styling, Authors are questioning why this is.

I also wonder. Why is there a horizontal adjustment to skip-ink as the line gets thicker? (in this demo / a horizontal-tb writing mode).

I would prefer that the underline maintains the horizontal-lengths seen in the second example, no matter how thick the lines are. And I believe most typographers will want the same.

Was this intentional? Is this in the spec? Or is this an implementation detail that was left up to each browser, and the engineers that have done this work just happened to do it the same way?

https://drafts.csswg.org/css-text-decor-4/#line-position
https://drafts.csswg.org/css-text-decor-4/#text-decoration-width-property
https://drafts.csswg.org/css-text-decor-4/#text-decoration-skip-ink-property

[jfkthame]

Some sensitivity to the line thickness is probably desirable. If we used gaps as in your second example when the underline is a hairline, they'll look much too wide; a fine underline should come much closer to the glyph descenders.

But some kind of limit to the gap width is probably good, so that it doesn't grow ridiculously wide. (Although IMO using skip-ink with very thick decorations probably isn't a great idea anyway.)

[litherum]

fine underline should come much closer to the glyph descenders

Yes, exactly. When I implement this, I first made them have no effect, and it was ugly. Making them have an effect made it less ugly. Perhaps we could “solve” this issue by fine-tuning the relationship better in browsers (now it’s just linear in WebKit)

[Loirooriol]

I don't know about typography, but with such enormous underlines I would expect something like

Note the spec has this example where the underline follows the curvature of the glyph:

[jfkthame]

This would require an entirely different approach to implementation than I believe any of the browser engines are currently using. (Not saying it's a bad idea, but the current implementations aren't going to produce that effect.)

[litherum]

When I implemented ink shipping originally, I implemented that behavior first. It turned out to:

1. Be too slow. It involved offscreen masking and stuff that was way slower than just drawing some lines
2. Leave little bits of underlines inside bowls of letters like lowercase g. These were too ugly to ship.

So I switched to a different design.

[Loirooriol]

@litherum Seems reasonable, but then I would at least expect

That is, just clip the underline outside the rectangle determined by the maximum descender of the font and the width of the character. But paint the underline below that in case it's thick enough.

[jfkthame]

I think that could look quite odd if some glyphs had much deeper descenders than others.

[Loirooriol]

Taking the deepest one among all glyphs in the font would make it look good (unless the font changes)

[litherum]

There are a million things we could do. We could use the mask approach but try to find "islands" and remove them. We could do @Loirooriol's idea. We could use trapezoids. We could keep doing what we're doing now but have the relationship be non-linear.

This space is ripe for experimentation. The spec shouldn't dictate what to do here.

[jensimmons]

Hey look, @jfkthame just changed how Firefox handles this.

Firefox release currently does this:

Now Firefox Nightly (as of Nov 8, 2019), does this:

Ah, much better. It looks great to me.

[jensimmons]

The ticket for this is https://bugzilla.mozilla.org/show_bug.cgi?id=1594843
"Clamp the maximum padding between decoration line segments and glyphs when applying text-decoration-skip-ink".
I believe he applied a 1/5em clamp.

[SebastianZ]

Leave little bits of underlines inside bowls of letters like lowercase g. These were too ugly to ship.

Regarding this, there are cases where you'd want to have the underlines inside glyphs. I've opened #4504 to discuss this.

Sebastian

[fantasai]

IIRC we decided to leave the question of how much gap and what fragments to delete up to the UA as a quality-of-implementation issue. So closing out this issue as the spec doesn't need adjustment (it let's you do whatever), but feel free to keep discussing.

[jensimmons]

It makes sense to me that we leave most of this up to implementors — there's certainly a lot of detail to figure out when it comes to multiple scripts, and the CSSWG can't spec all of it. But can we put a note or something in the spec, a suggestion, that UAs look at this interaction between two properties, and consider clamping the gap at some reasonable (up to them) setting? This will drive Authors (& their designers/bosses/clients) nuts if we don't have vague interop on this. It'll render combining a thick line with skip-ink unusable. (Sadly, despite repeated teaching that websites do not need to look the same in every browser, folks don't believe it, and they end up saying "such & such is too buggy never use it". And it's banned from use.)

We don't need every browser to do it the same way, or set the same clamp. But we do need them to consider not leaving a giant space around skipped-ink when the line is thick.

A note / suggestion of some kind? And well, /me waves to @litherum to think about this...