[css-text-decor] Limits on text-underline-offset to preserve semantic meaning

[litherum]

If an author puts text-underline-offset on an underline in a naive implementation, they could potentially make the underline look like a strikethrough. When this content is viewed on an older browser that doesn't support text-underline-offset, the semantic meaning of the text will appear to be changed (from struck-through to underlined). This is unfortunate. Instead, implementations should try to restrict the offsets on underlines so the underline always looks like an underline, rather than a strikethrough or overline.

There are a few questions to designing this:

1. Should the specification prescribe specific rules about where these limits are, or should the spec simply say that implementations should attempt to solve this problem?
2. Regardless of the result of 1, the spec should probably at least suggest some rules. So, what should the suggested rules be?
   1. The close-edge boundary for horizontal Latin text should probably be the baseline.
   2. What about Hindi text, that uses a hanging baseline?
   3. What about vertical text, where the baseline is at the same place a strikethrough should be?
   4. The underline is supposed to be one consistent stroke, regardless of the presence of child elements of differing sizes. Should a super large font-size child element push the limit outward?
   5. How about the other direction; the underline of one line of text shouldn't be able to look like an overline on the next line of text. For simple paragraphs this is probably straightforward, but what about when various elements on the next line have differing line-heights? Different sizes?
   6. Do we take in the border box of the containing block into account?

[jensimmons]

Having some kind of limit to prevent authors from mis-using underlines (overlines, sidelines, and such) sounds like a good idea to me. I feel strongly that whatever the limits are, we get interop on them (through the spec), so that Authors don't invent new hacks around this space — using the new powers we are adding to underline (et al) (thickness, placement, color, kind, etc) — that don't work the same in every browser.

Here's a drawing of different underline results that Authors might want to use, none of which cause a misunderstanding of strikethrough. Might be helpful for discussion. I'm seeing a lot of designs lately that use something like v4 to style underlines. File under Hot Trends of 2019.

[litherum]

none of which cause a misunderstanding of strikethrough

Even Sample text 5?

[AmeliaBR]

I agree that 1-4 in Jen's samples are all valid underline styles. Yes, the position in 3 & 4 overlaps the text, but it is clearly still near the baseline and there is sufficient color contrast between the text and underline that it doesn't look like a cross-out.

To cover these situations, we could define a clamp such that the mid-point of the under/over line is never moved inwards by more than ⅓ of the distance between the normal underline position & the normal overline position.

If we accept sample 5 as a valid underline, then we'd be basically giving up on the idea of clamping the values at all. However, it's also not a valid strike-through text decoration (since that would be painted on top of the text). So this effect would continue to be dependent on background gradients. I'm OK with that; what I see when I look at it is text with a background effect. But, if authors are using it to have the same semantic meaning as an underline, then we have to consider that underlines are communicated to assistive tech & are preserved in simplified CSS environments, but background images are not.

Another use case to consider: animating this value. If an author is trying to create an animated hover effect with the line sliding into position, then interpolating an offset length is much easier than trying to swap between underline, strike-through, and overline. Which again would argue for no clamping.

[jensimmons]

Even Sample text 5?

Let's see....

[AmeliaBR]

we could define a clamp such that the mid-point of the under/over line is never moved inwards by more than ⅓ of the distance between the normal underline position & the normal overline position.

BTW: defining it this way — relative to the normal text-decoration positions instead of relative to baseline positions — avoids adding any special rules for clamping based on text with different baselines. (The special rules would still exist, but in the calculation for where to put the default under/over line!)

[nigelmegitt]

Is the difference between underline and strikethrough that an underline is drawn behind the text and a strikethrough in front, i.e. a drawing order difference? Then the only time when strikethrough and underline are indistinguishable is when they are the same colour. My guess is that is probably the majority of the cases in actual use so worth avoiding.

I'm not suggesting making the clamping behaviour dependent on colour contrast between the line colour and the text colour, just to be clear.

[litherum]

@jensimmons That screenshot makes it look more like a highlight than an underline. I wonder if background-image would be a better fit for that case.

[litherum]

This conversation is making me think

1. We shouldn't be encoding 2019's design trends into CSS
2. There is enough design taste and fiddly-ness here that the spec probably should just let implementors decide the best solution for now, and write down whatever the implementors collectively decide is best.

[astearns]

FWIW, designers often use underline offsets and weights in InDesign to create custom text highlights (for the past decades, not just 2019). I was assuming the web versions could be used for the same purpose. I'm not sure the worry about confusing a custom underline for strikethrough is worth limiting flexibility here.

[dauwhe]

Historically, CSS gives us freedom to do many things, like position elements off the screen, overlap text, and so on. Users of CSS have taken advantage of this freedom by using features in ways that weren't anticipated by their creators. There's a rich tradition of such "hacks" in the design world, especially with underlines, borders, etc.

I'm a bit wary of restricting what clever people can do, in the absence of documentation of harm.

[jensimmons]

We shouldn't be encoding 2019's design trends into CSS

I agree. But we aren't talking about encoding a design trends into CSS. We are talking about whether or not to limit what's possible, or rather where to place that limit. And I'm saying, we should not limit something that people clearly want, even if they only want it for a short time. Trends do come back around. And this is a big one right now. These trends also tend to point us in the direction we, the CSSG, need to move. That's why we made border-radius for example. Rounded corners were hot right before CSS could do it.

[jensimmons]

I made a demo while diving deeper (so I could understand the issues better).
https://codepen.io/jensimmons/pen/wLrjGG?editors=1100
This works today in Safari.

At the moment, in the Safari implementation, a negative or zero value for text-underline-offset makes the underline disappear. This is unexpected. And, imho, not desired.

I do believe there are legitimate reasons to allow Authors to pull the underline up to be behind the text ("up" in the horizontal writing mode). I really do not like the clamp that prevents this.

At the moment, if one browser allows a negative value, while another makes the underline disappear with a negative value, we'll have a nasty interop problem.

I would prefer we remove any clamp, and expect Authors can be responsible.

[Andy-set-studio]

Howdy all 👋 first time caller, long time listener.

I'm skeptical about a negative offset purely because of accessibility concerns, but after seeing the demos on here, I can see an opportunity from a creative angle, which is great.

Would there be a way that if say, the colour contrast between the underline and its text fell short, the underline would vanish like it does now?

[jfkthame]

At the moment, in the Safari implementation, a negative or zero value for text-underline-offset makes the underline disappear. This is unexpected. And, imho, not desired.

This isn't what I observe in (Safari Tech Preview); a negative or zero value works as expected to move the line. However, Safari's skip-ink behavior means that it's likely to disappear "behind" the letters, particularly if you're using a thick underline, unless the offset is so negative that it actually moves entirely above the text. (And Safari doesn't support text-decoration-skip-ink: none, so you can't turn off the skipping for an "underline" that overlaps the body of the letters.)

I would prefer we remove any clamp, and expect Authors can be responsible.

I agree. I don't think there's any real basis for deciding on a clamp value. If authors want to put the line far away from the text, or move an "underline" to be above, or whatever, that's their business, not ours. We may consider it unwise, but it's not CSS's job to decide on arbitrary limits to design.