[css-text-decor] text-decoration level 4 clarification on text-underline-offset positive/negative lengths

[charliemarlow]

For text-underline-offset at https://drafts.csswg.org/css-text-decor-4/#underline-offset, it says that "Positive lengths represent inward distances; negative lengths outward". This seems to suggest that a positive length would move the underline up, intersecting with the text that it is underlining and eventually sitting "above" the text like an overline. A negative length, however, would travel "down" the page. Is this the correct way to interpret that section of the spec?

In Safari Technology Preview 70, text-underline-offset has been implemented, but positive values move the text downwards on the page away from the underlined text. Negative values have the same effect as setting text-underline-offset to 0.

[emilio]

cc @litherum

[jfkthame]

Trying to think as an author, it seems more natural to me that a positive text-underline-offset would move the underline away from the baseline of the text (so downwards, in common horizontal-tb writing mode). That's what Safari Tech Preview does, but it's the opposite of what the spec currently says, as I understand it.

Given that AFAIK no-one else has implemented this yet, I'd suggest the language in the spec should be reversed so as to match Safari's behavior.

Negative values have the same effect as setting text-underline-offset to 0.

Just FTR, this isn't what I see: in Safari Tech Preview, negative text-underline-offset moves the line up through the text, or eventually entirely above it. Which is what I'd expect, modulo the reversal of direction compared to the current spec draft.

[dbaron]

I'd note that I had experience in the distant past dealing with different OS APIs for underline offsets (the underline offset that comes out of the font metrics) having different signs. So there's a historical precedent of inconsistency in this space.

[kojiishi]

Given that AFAIK no-one else has implemented this yet, I'd suggest the language in the spec should be reversed so as to match Safari's behavior.

+1.

[css-meeting-bot]

The CSS Working Group just discussed text-decoration level 4 clarification on text-underline-offset positive/negative lengths, and agreed to the following:

• RESOLVED: Update the spec so positive offsets are outward from the text

The full IRC log of that discussion

<dael> Topic: text-decoration level 4 clarification on text-underline-offset positive/negative lengths
<dael> github: https://github.com//issues/4021
<dael> dbaron: The commentor is a Mozilla intern implementing
<dael> Rossen_: Can you represent?
<dael> dbaron: Maybe emilio
<dael> fantasai: There's a text-underline-offset prop that takes a leg to adjust underline position. Postive is inward and negative is out. Negative goes down on an underline. Safari impl opposite.
<dael> fantasai: Does something different.
<dael> fantasai: Prop is positive values move outwards. Down for horz text
<dael> fantasai: Seems fine to me. I don't understand what Safari is doing
<dael> dbaron: Sounds like which direction things move it.
<dael> dbaron: Apparently Safari treats negative as 0
<dael> fantasai: Okay
<dael> fantasai: I don't have a strong opinion. I'm fine if positive moves outward
<dael> AmeliaBR: As someone with no experience I'd expect positive and negative to map up/down consistent between under and overline. Or I'd expect positive to be father from text. Large values meaning closer to text for over and under seems weird
<florian> agree with AmeliaBR
<dael> myles: Couple things. First I want to say when I impl this was an oversight not trying to twart spec. We have a clamp b/c worried about content spec underline and do offset that looks like strikethrough but a browser without it looks like underline and that changes meaning. We did it can't be closer than baseline.
<dael> myles: Wanted to do other direction too but never got around to impl that
<dael> myles: AS far as positive and negative directions I believe they're just flipped. That's and oversight, I'm sorry. Happy to switch. But the person opened the issue said match Safari. I don't have a preference here
<fantasai> myles, given Amelia's logic, I think it might have been a good thing you misinterpreted the spec :)
<dael> jensimmons: On question on if positive moves away from text rather than closer with margin and padding there's a cowpath in author minds where if there's a border and you add postive it moves away and negative is closer.
<dael> jensimmons: Instinct is Safari way makes more sense to author minds
<dael> fantasai: prop: Change the spec. I think there has been good arguments.
<dael> fantasai: Arguments against changing to match Safari?
<dael> Rossen_: None against. Is what myles desc for clamping in spec? That is good behavior to me and maybe to spec. That values can't go beyond baseline in negative direction? Maybe something like baseline+ascent in positive?
<dael> Rossen_: Prevents underlines being used as strikethrough
<dael> fantasai: Seperate issue so let's address separately. Good point, let's close this.
<AmeliaBR> Agree these are separate issues. But +1 for a second resolution to support clamping the used values to avoid under/overline looking like strikethrough
<dael> fantasai: Prop is update the spec fo positive offsets are outward from the text
<dael> Rossen_: sgtm
<dael> Rossen_: Obj?
<AmeliaBR> s/fo/so/
<dael> RESOLVED: Update the spec so positive offsets are outward from the text
<jensimmons> Thanks myles for "doing it backwards" so this would come up and we could make it better!
<dael> fantasai: Thanks to myles for making a mistake, we have abetter spec
<dael> fantasai: Second, I understand logic for having clamping. Happy to add spec text, but need to think about reasonable limits. ascent on upper is too high.
<dael> Rossen_: Yep. Let's open as sep issue and figure out limits
<dael> myles: You want me to open?
<dael> Rossen_: Please
<dael> Rossen_: Anything else on this?
<dael> jensimmons: Preventing using it as a strikethrough I'd love to see clear interop and clear spec. That's exactly what authors will try and do and if they're able in one and get annoyed if they can't in another. I vote interop on that whatever it is.
<dael> myles: I'm interested in this. You think there should be interop in all browser try and prevent or don't? Or in specific algo for limits?
<dael> jensimmons: Need to think more about what diff in limits might be. If it's minor and technical I think doesn't matter. If you can have a cool background for some text with underline in one browser or not another that's a problem.
<dael> Rossen_: I think there's consensus we want interop. Let's take this coversation to the new issue and let's get to something that can be impl by all
<dael> fantasai: Want to point out jensimmons comments made me think it's worth nothing underline is under text not on top. Won't be same as strike through.
<dael> Rossen_: If same color it will be
<dael> fantasai: Could be reasons you want a thick baseline that you shift up.
<fantasai> s/baseline/underline/
<dael> Rossen_: This is why we need a new issue. This is not a 4 minute discussion
<fantasai> s/nothing/noting/

[jensimmons]

We just resolved on what this should do, and I believe we resolved the correct way (ie, what Authors want/expect). But since doing polls on Twitter is far too easy, I thought, heck, let's see what hundreds of random people think.... So here's a poll. It will likely confirm we did the right thing: https://twitter.com/jensimmons/status/1143945231152422914

[jensimmons]

Rationale for 1: its more like outline-offset where a positive offset value pushes outwards. — https://twitter.com/dorebank/status/1143945887120596994

[dbaron]

Also note that #4059 was spun out of this discussion, covering whether there should be limits on how far text-underline-offset can go.

[fantasai]

This was fixed in 9d6d9fa