[css-text-decor] ink skipping should conform to glyph shape

[fantasai]

Toby Reif is complaining about the exact shape & distance of the ink-skipping gaps. https://twitter.com/TobiReif/status/839809400529383424

I don't think we should define the distance--we don't have a good answer there--but it might be worth recommending that the shape should follow the outline of the glyph. Would there be any objection to adding such a should clause?

[tobireif]

I wasn't complaining. Instead I was constructively pointing out a detail where browsers render something differently from the image in the spec

"The spec shows the line endings cut off based on glyphs, while Chrome and Safari have square endings"

so that you can consider specifying eg one of the options.

Ideally there'd be a clearly defined default (eg follow the glyph shape), and perhaps also an option for setting eg square line endings.

[kojiishi]

@drott

[litherum]

While implementing this in WebKit, we found a few things:

1. You are right that the inside curve of the underline should follow the curve of the letter (typographically).
2. Using a mask-based approach is too slow. It's a deal-breaker.
3. Even when we used the mask-based approach, the mask would leave little underline floaty bits inside the lower loop of lowercase "g". These are typographically bad.
4. Our current approach is just to draw rectangles. However, one day we want to move to a trapezoid-based approach. Because most underlines are thin, this approach will probably be the best balance between performance and typography.

Maybe some implementations with less of an emphasis on speed want to use the mask based approach. Maybe even other want to use the mask-based approach, but somehow detect and eliminate the floaty bits. Browsers should be able to innovate here. The exact behavior should not be required / specced.

[tobireif]

From my POV (one web developer) it would be ideal to have a specd default (any, eg based-on-glyph-shape) so that the default rendering is consistent in all browsers. Browsers sure are free to experiment/innovate eg by offering options to developers (eg first behind flags), but it would be great if everyone could agree on one default option for the rendering of underlines.

Plus eg three options that the web developer could set (eg square, trapezoid, based-on-glyph-shape). Then the web developer could decide, incl the perf trade-off.

Regarding your #3: This should be solved by implementers.

Regarding your #4: Some are thick. Ideally you'd let the CSS user (the web developer) choose and decide per case regarding the trade-offs.

[kojiishi]

I don't feel strongly either way, but having a should clause is unlikely to help us. Rather, I'm worried about negative side effects, so I tend to agree with @litherum.

I think filing bugs to rendering engines would help much better.

[tobireif]

I don't see a bug that could be reported. Square underline line-endings are OK for some I guess. But there could be inconsistent rendering across browsers because the underline line-endings aren't specd at all.

worried about negative side effects

If there'd be options, CSS users could make the choice and could consider any trade-offs that are relevant per usage instance.

[fantasai]

A SHOULD clause would make it clear that conforming to the shape is the intended (goal) rendering. It looks nicer is one reason, but it also helps distinguish underline vs. diacritics, so following the outline is definitely the better option. However, RFC2119 SHOULD allows UAs to deviate if they have a well-thought-out reason to do so, and the perf concerns here qualify. https://www.ietf.org/rfc/rfc2119.txt

Wrt handling floaty things, I think saying “stroke endings should follow the curve of the glyph” is sufficiently lenient: the ideal rendering would probably be something like: UA determines where it can place underline segments by where a full-height underline segment of some minimum length would fit, and then each such segment's stroke ends are made to conform to the glyph outline. (Not suggesting we spec that exactly, just that such behavior would be conformant and reasonable.)

I do agree with @tobireif that not all underlines are thin (especially once we add text-decoration-width in L4), and in such cases the perf tradeoff would be more worth it. A UA that cares enough to implement the ideal behavior could switch it on above a certain threshold to maintain perf for the common case, though.

[css-meeting-bot]

The Working Group just discussed ink skipping should conform to glyph shape, and agreed to the following resolutions:

• RESOLVED: Add the statement that stroke should follow the curve of the glyph as well as adding a non-normative note that points out anything not captured in the GH issue and add better pictures.

The full IRC log of that discussion

<dael> Topic: ink skipping should conform to glyph shape
<fantasai> s/tweeked/tweaked/
<dael> github: https://github.com//issues/1093
<dael> fantasai: There was a complaint about how impl, when they cut off the underline they cut off a striaght line. You don't want the underline to stop with a blunt edge and then have a gap between glyph edges, you want it to follow the edges of the glyph.
<dael> fantasai: The spec doesn't say anything specific so I was thinking we could have advice, you should have underline edges hug glyph.
<dael> fantasai: There was a concern on performance which is why I'm suggesting a should. An impl could decide to do it if font size is large enough, but not in general case. That would resolve a lot of perf considerations. I think spec should offer this advice.
<fantasai> https://www.ietf.org/rfc/rfc2119.txt
<fantasai> proposed text: "stroke endings should follow the curve of the glyph"
<dael> myles: You can have a desc ofo good typography. There's more to good underlining then having it follow contors of glyph. You'll want a larger explination of good typography of underlines and that doesn't feel like it should be a normative description. It feels another spec or note.
<dael> florian: Are they big enough that they cannot be phrased as shoulds?
<dael> florian: Do you think it's too high level for normative?
<dael> myles: Yeah.
<dael> myles: If you're going to have a couple paragraphs on good typography it shouldn't be normative.
<dael> Rossen_: I'm hearing one proposal for adding the should which suggests how a good typography works for underlining and I head some push back on why is this normative and not informative somewhere.
<dael> dbaron: One comment on myles statement. I don't want to get into a situation where you need to be an expert in other fields to impl the spec. The spec ought to say what you need to do to impl. If there's advice on good typography that should be known by an impl it should be on the WG to have that as part of the behavior the spec desc.
<dael> myles: I think the spec does that as is.
<dael> fantasai: It desc certain nec. things. We'd like the impl...given the option we'd say yes you should have the curve follow the glyph curve. What follow means, you have to think about that, but that's why we shouldn't be over specific. That's why we word things with an appropriate level of specificity so you know what to do.
<dael> myles: Point I was trying to make...for ex if the spec says underline shoudl follow control of glyph and impl could use mask-base and then you have underlines in the curve of the g and htat's worse typography. If you're going to have this it needs to be much longer. If it's a general of how underlines should work...
<dael> fantasai: Typography is very broad. If you want more desc on ways you can mess thi sup, that's fine. typography of underlines in general is out of scope for this.
<dael> myles: Right. Doing this..
<dael> fantasai: It's not out o scope for the spec. L4 has the ability to adjust underline and will have much more detail. This topic isn't position, this is where you don't draw a line. A desc here should assume position and thickness was chosen already.
<dael> myles: I'm not talking position and thickness.
<florian> q?
<dael> Rossen_: myles is your push back on adding this statement very strong or is this something you can live with.
<dael> myles: I'm not going to object.
<dbaron> If the spec says "use the position and thickness specified in the font metrics" then position and thickness aren't something that implementors need to think about
<dael> Rossen_: Okay. And fantasai if this was a non-normative note would you be okay or would you pref the should.
<dael> fantasai: I'd prefer the should so it's clear to impl this is the behavior that we want. We can add a note saying there's things you need to watch out for and if myles wants to point out anything not in the issue when doing the note I can add that.
<dael> Rossen_: In summary you propose to add the scroke of the underline shoudl follow the curve of the glyph. That's the text?
<dael> fantasai: Yes and a note ot address myles concerns.
<dael> myles: We should also add a picture because the one in the spec is 2px tall.
<dael> fantasai: Good idea. We can have some of those g
<dael> dbaron: Will the note have the thing about maybe only large font sizes?
<dael> fantasai: I can do that.
<dbaron> s/only/doing it only at/
<dael> Rossen_: Proposed resolution: add the statement that stroke should follow the curve of the glyph as well as adding a non-normative note that points out anything not captured in the GH issue and add better pictures.
<dael> RESOLVED: Add the statement that stroke should follow the curve of the glyph as well as adding a non-normative note that points out anything not captured in the GH issue and add better pictures.
<fantasai> s/not captured/captured/

[tobireif]

Thank you all!

[fantasai]

OK, checked in! @litherum, would you mind looking things over to make sure the note captures everything you want it to say? I'm happy to take suggestions for improvement.

[litherum]

"typographically-awkward wisps of underline"

Looks good.