Csswg-drafts: [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.

[hankchizljaw]

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.

[jpamental]

I agree that we shouldn't limit the placement. @jensimmons examples show legitimate design use cases. There are indeed many other ways people can use CSS in ways that don't make sense. This one is purely presentational. In some cases I would agree that a background gradient would be a better option, but as @AmeliaBR points out, the actual text decoration would still be preserved for screen readers and more limited CSS implementations. So it would still work as it should. I don't think it should be clamped.

Once more browsers are implementing this, I'd certainly hope that more the text-decoration spec would be implemented in Safari as well (instead of being a 'similar but not quite the same' behavior it is now with ink skipping)

[jensimmons]

I made another drawing that's better than the one above — a clearer drawing of the use-case I would like to allow.

If there were a mid-line to clamp to, I'd be ok with that. But I'm not sure we have a good line in the font files to use. I don't like clamping to the baseline.

As @dauwhe & I chatted today about what's available in a font file, he mentioned perhaps "between x-height and descent". I guess we could cap at x-height? I'd be totally fine with that. Or at a calculated mid-point between the x-height and the descent? Could that be a thing? That is what this drawing basically shows.

[jonjohnjohnson]

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)

IMHO this is the primary concern. Can't we simply evangelize progressive enhancement by use of @suports as its solution? Instead of limiting designers/developers creativity by clamping the placement?

[BillGoldstein]

When I first tried a test with Firefox' new implementation TRY build, I intuitively tried positive value, saw it didn't work as I expected, then went and read spec text carefully. So my "vote" would also be positive values being away from the text, i.e. down for underlines.

Also, please no clamping to just positive values...at least without also adding a new text-overline-offset property. Currently text-overline-offset can be simulated with text-underline-offset.

[AmeliaBR]

at least without also adding a new text-overline-offset property

Wait, this property _only_ applies to underlines? I missed that. I was definitely assuming that it would apply to both over & underlines. But using a very-offset underline to simulate a slightly offset overline seems like a hack. If that feature is necessary, let's define it directly. @BillGoldstein, do you have any screenshots of cases where you are using overlines & need to tweak their position?

[fantasai]

@AmeliaBR Yeah, you wouldn't necessarily want the same offset for the underline and the overline. :)

[BillGoldstein]

https://billgoldstein.name/about but you'll need this FF build https://treeherder.mozilla.org/#/jobs?repo=try&revision=e2f9053a82dd6aaef208c2d5a51f828aa8157ab8

[AmeliaBR]

you wouldn't necessarily want the same offset for the underline and the overline.

Definitely. So there would need to be a two-value syntax. Or as Bill Goldstein suggested, two different properties, though I'm not sure they need to be separate: you're either going to set them both at the same time you set text-decoration to have two lines, or you're going to set them both when you set the font to something that doesn't work well with the default line positions.

Anyway, that's a separate issue. My point was, if there's a use case for adjustable overlines, it should be addressed directly, not as an argument for extreme underline offsets.

[jfkthame]

I wondered about this, too (the ability to control underline position, but not other decoration lines); it seems a bit inconsistent. The only explanation I could think of was that underlines are much more commonly used (e.g. to indicate links) than overline or strikeout, and so people care more about them.

But if we're going to complete the set, presumably we also need text-line-through-offset, or a three-valued text-decoration-line-offsets. The default position of line-through doesn't always look particularly good.

[BillGoldstein]

"The default position of line-through doesn't always look particularly good."

This is noticeable with thick(ish) text-decoration-width values.

[dauwhe]

I worry that clamping can result in a bad author experience. It's quite frustrating when you change the value of a property but there is no visible change. Even worse is changing a value of the property and the line disappears.

More generally, why is CSS now restricting what authors can do? I can create unreadable text in a thousand different ways. CSS gives authors tremendous power, and talented people can use features in unexpected and beautiful ways. Is it the role of the CSS Working Group to say that some designs are OK, and some designs shouldn't even be possible?

[css-meeting-bot]

The CSS Working Group just discussed Limits on text-underline-offset to preserve semantic meaning.

The full IRC log of that discussion

<dael> Topic: Limits on text-underline-offset to preserve semantic meaning

<dael> github: https://github.com/w3c/csswg-drafts/issues/4059

<dael> jensimmons: txt-underline-offset lets authors move up and down, speaking in latin. negative is up, positive is down, 0 is baseline.

<florian> q+

<dael> jensimmons: impl is in Safari and they clamped it to avoid turning underline into strikethrough. In Safari clamp was at any negative number and what happens is it disappears. Impl in FF behind a flag. When I've been looking at this last image is best. I think legitimate use cases to let it rise up. Do we want to have any kind of clamp? Maybe want to prevent use as strikethrough and have a mid-line clamp. Or we say no clamp, we'll trust authors.

<jensimmons> https://codepen.io/jensimmons/pen/wLrjGG?editors=1100

<dael> jensimmons: You can style strikethroughs, though you can't move upa nd down.

<dael> jensimmons: Codepen in irc if people want to look at this

<AmeliaBR> q+

<myles> q+

<Rossen_> ack florian

<dauwhe> q+

<dael> florian: I agree with jensimmons Use cases seem legit and I wouldn't want to block. If we want generous clamping or no clamp is different. All jensimmons cases have different color on underline. If it's same color could be different.

<dael> fantasai: We have a shorthand that lets you set both.

<bradk> +1 no clamping at all

<dael> Rossen_: Making properties depend on each other is not great.

<Rossen_> ack AmeliaBR

<fantasai> +1 to Rossen

<dael> AmeliaBR: I agree these are neat effects. Important to recognize different text decor have different semantic meanings. strikethrough is different then underline.

<bradk> Underlines are behind the text and strikethroughs are in front of the text right?

<jensimmons> AmeliaBR that's why I explained how strikethroughs can be styled.

<astearns> bradk: yes

<dael> AmeliaBR: Don't want to encourage wrong text decoration because one has a lot of flexibility in rendering and the other doesn't. There will always be rendering in less complete css impl. And the basic is on the a11y tree where it's this is an underline or a strikethrough

<dael> AmeliaBR: As far as outcomes for clamping, I don't nec. mean need to clamp

<jensimmons> bradk — yes. Underlines are behind. Strikethroughs are in front.

<bradk> Text decorations are not semantic

<dael> AmeliaBR: We want to encourage people to use correct text decor. If a visual effect is past the point where it really is an underline it shouldn't be represented by an underline. If the visual effect is a strikeout it should be using one. If facilities for a strikeout modification aren't as good as an underline might be a problem.

<dauwhe> q?

<dael> myles: Suggesting add same controls on strikethrough?

<dael> AmeliaBR: Might be nec.

<bkardell_> q+

<Rossen_> ack myles

<dael> myles: Thanks for all these examples jensimmons. I think you've shown where we draw the boundry is not the right place. It is important to distinguish between the 2. I think UA should be allowed to place limits. Perhaps ours are not best

<jensimmons> q+

<dael> myles: Would be bad if in one browser look struck through and other looks em. I would prefer a should try and distinguish between strike through text and underlined text. Once those limits are agreed can spec

<Rossen_> ack dauwhe

<dael> Rossen_: We're not hearing dauwhe

<Rossen_> ack dbaron

<dauwhe> q-

<Rossen_> dauwhe: can you perhaps summarize over IRC at least?

<dael> dbaron: I was on queue to suggest that given problems we may want text strikethrough offeset sooner. jensimmons said in introduction that 0 was relative to baseline rather than initial position. If going to add strike through and maybe overline offset might have different conclusions of 0

<bradk> +1 Offset overline and strike-though offsetting.

<dael> fantasai: 0 depends on text underline position porperty. It defaults to alphabetic-ish. If we get specific offset we snap to alphabetic offsel so you ahve something stable. If you chose a different position that becomes origin of offset

<dael> dbaron: Okay. Given concern...seems likely authors will use underlines for things not underlines if we give them more controls then strike through and overline. Esp strike through. I rec. it's a lot of properties but it's work thinking through.

<dael> myles: We've heard plenty of authors asking for underline control. I know of 0 for strike through and overline.

<bradk> Why not text-decoration-offset?

<bkardell_> q-

<jensimmons> q

<dael> Rossen_: Because they can do it with underline. Only partly kidding. We don't want to give something where they use underline all the time

<dael> dbaron: Poss want single property to move all

<dael> fantasai: I don't think so. If you have 2 or 3 might not want up by same amount

<astearns> I'm a bit worried about hacks to get around clamping - adding a blank line to the beginning, then giving an underline a large offset to move it to the next line below gets you back into the 'looks like strikethrough' case

<dael> dbaron: But 2 or 3 is rare so not clear worth another property

<fantasai> dbaron, text-undelrine-offset inherits

<fantasai> dbaron, so that you can set it once and forget about it

<Rossen_> adk jensimmons

<Rossen_> ack jensimmons

<fantasai> dbaron, so making it apply to all the lines wouldn't be very usable

<dael> jensimmons: I agree with dbaron we should think about strike through and overline to mitigate abuse of underlines. Maybe they haven't asked for but lots of things with typographic get lumped in one giant bucket.

<astearns> +1 to interop - I don't see a big need to allow UA inconsistency here

<fantasai> +1 to astearns and jensimmons

<bkardell_> q+

<dael> jensimmons: Also think we shoudl have interop. I don't want too lose for browsers because could be painful for authors. If in one browser underline looks great and an untested browser the underline disappears is dangerous. I think disappearing is bad. Maybe have it not move so if you say -10 it clamps and doesn't move.

<dael> jensimmons: I would be fine with a clamp if it's a magical mid-line. Maybe at x height?

<bradk> +1 to dbaron and jensimmons

<Rossen_> q?

<AmeliaBR> +100 to clamping (if it is used) being clamping the offset, not making the underline disappear

<dael> jensimmons: Some of the things in the issues like check for color contrast could get really complex and over engineered and hard to impl. I want to keep simple and make it possible to impl. I'm not a browser engineer maybe it's easy.

<dael> myles: One other point is if underlines can go arbitrarily far you might have to scroll down 5 pages to get the underline. So if you invalidate one piece of content you have to redraw whole page.

<dael> jensimmons: Makes sense to have a clamp to the line box.

<dael> dbaron: I think underlines are visual but not scrollable overflow

<dael> myles: Yes, but if page is 3 viewports tall might be at bottom

<dael> Rossen_: Yeah, I'm with dbaron .

<dbaron> s/visual/ink/

<dael> Rossen_: Are we considering underlines that are visually...missing th term but the ones that break underline when something else is around. Or is this jsut solid line segments

<Rossen_> q?

<dael> myles: Skipping in our impl only considers text the underline is on. It won't skip next line of paragraph

<Rossen_> Zakim, close queue

<Zakim> ok, Rossen_, the speaker queue is closed

<Rossen_> ack fantasai

<Rossen_> dauwhe, can you talk yet?

<dael> fantasai: I wanted to agree with jensimmons. Making argument about if underline should allowed to be ihgher because we thinks so, don't want that clamp. Reasonable distance of text clamp makes sense. Needs to be able to leak outside line box, but not by lots. Maybe text 1.5

<jensimmons> +1 for allowing past the line box — yeah, maybe can't be two lines boxes away or something

<dael> fantasai: I think jensimmons case of using central baseline is fine.

<jensimmons> right now, btw, Safari allows any distance down — will go very far. There's not a clamp yet

<dael> myles: For small text it's hard to get underline, like 5pm text, hard to get it in the linebox. Has to have case outside line box. Some general same clamping is important. Prob not where our impl does it today.

<dael> Rossen_: bkardell_ you're next

<dael> bkardell_: My questions are big so will ask in another forum

<dael> Rossen_: I don't think we'll resolve. Meta idea of if we want any kind of clamping.

<fantasai> myles, I'd use the greater of the line box boundary or slightly outside the descent (e.g. 0.25em past descent or 0.5em past descent)

<dael> Rossen_: I rememebr last time we discussed we resolved to continue work. Without specific number or formula can we resolve we want some kind of clamping for underline offset? THat way we know we have a direction and won't have half group say no clamping.

<tantek> could it be clamped to the linebox?

<dael> fantasai: I think need to decide if clamping to enforce underline-ness or if we're looking for reasonable distance of text

<fantasai> tantek, no, because line box can be smaller than the text

<dael> Rossen_: Both require clamping.

<tantek> to resolve the "underline down to page 5" problem

<fantasai> tantek, see my comment to myles above

<tantek> fantasai is there some box that contains the text?

<dael> Rossen_: In favor of continuing discussion. Can we resolve we want some clamping as part of underline offset either to enforce semantic meaning of underline or to keep it within visual distance

<dael> bkardell_: I heard different things talking about semantics. I don't know that someone can explain what they mean in a minute. the semantics seem wishy-washy

<florian> I want clamping for one, not the other, so I'm not sure what to do about a resolution to clamp for either...

<dael> fantasai: We all agree clamping withing reasonable distance of text is something UA can do

<dauwhe> https://github.com/w3c/csswg-drafts/issues/4059#issuecomment-510145258

<dael> AmeliaBR: If we allow visual effects, we allow them. I don't see a reason to clamp in either direction.

<tantek> I'm (a little) worried about the effect on printing, e.g. do text decorations count as part of widows and orphans computations?

<astearns> box-shadow not clamping is a good argument against not clamping here

<dael> Rossen_: Let's continue that in the issue.

<bradk> -/+ 1em clamp

<dael> fantasai: Can we resolve on being able to clamp within range of text?

<dael> Rossen_: That's what I was pushing for.

<dbaron> I'd note *normal underlines often extend outside the font's bounding box at the bottom

<bkardell_> I'm fine with that much

<dael> fantasai: Just resolving a clamp to keep line in reasonable range of the text

<tantek> would prefer more discussion before a resolution on this - that seems too wishy washy

<dbaron> (especially if they're wavy, etc.)

<dael> AmeliaBR: I have an objection. I don't see that as a strong argument. Paint can be all over page from box shadow.

<tantek> defer resolution please

<dael> jensimmons: It's after the hour, I think need to do another time.

<dael> Rossen_: We'll do that next week.

<dael> Rossen_: Thank you everyone, we'll continue next week.

[astearns]

+1 to @dauwhe. I don't think we should have any clamp for this offset.

[jensimmons]

After the discussion on the call, it seems like there are three options:
1) No clamp — allow anything. Leave it to Authors to be responsible.
2) Wide clamp — allow all kinds of visual styling that might be wrong semantically (bending the purpose of 'underline'), but do clamp enough so that the underline for one string of text doesn't end up three line boxes away or further (like on another page/screen).
3) Narrow clamp — clamp tighter, to prevent Authors from putting the underline across the ascenders, for example, so that it's not possible for an underline to loose its semantic meaning.

If we decide on one of these three, then we can debate the details of how to do it (if we choose option 2 or 3).

We also debated:
1) Should the specification be precise, with musts, so that there's interop in the details?
2) Allow implementers to figure out some of these details for themselves, and spec with mays or shoulds. Don't worry that it's inconsistent between browsers, and see how things work out. Perhaps spec details later?

[jensimmons]

I believe we should have interop, and that having this behave differently in different browsers will be a serious problem for Authors.

I also believe that — if we do clamp — the line should not disappear. It should just stop moving / appear at the clamped value. Having it disappear leaves a box of mystery for Authors to debug. And a serious interop bug trap waiting to eat people's underlines in untested browsers.

I lean towards no clamp at all. Let Authors do what they want. If people can change the color of a strike-through, and change it's thickness, they can style them however they want, separately.

If we want to do a wide clap (option 2 above), so that an underline can't end up on the wrong page (in paginated cases), or mess with paint performance, I could agree with that. But I would want it to be fairly wide, this clamp. I definitely don't want to get too fussy, though, and make this super hard to implement.

I agree with @dbaron on the call, we should look at doing text-strikethrough-offest and text-overline-offest asap, so that Authors can also adjust the placement of the line. That will remove the temptation to use underlines for these other use cases. Let all three have equal superpowers in styling, and tell people they should use the correct one semantically.

[AmeliaBR]

For what it's worth, I'm leaning towards "No clamp — trust authors to be responsible” _but_ with the requirement that we extend this feature so that anything that can be done visually with an underline can also be done visually with a strikethrough or an overline. That way, authors can pick the line that makes sense for their use case & that provides the most accessible fallback.

[bradkemper]

I also prefer no clamp at all (other than extremely large numbers that create memory problems, etc).

People can be very creative, and I don’t want to stifle the creativity with artificial limits. Some things mentioned after the call:

• @AmeliaBR: Reason to have an extreme offset underline: Fancy heading with mildly obnoxious hover effect that causes an underline to appear, but it doesn't just appear it slides into place from offscreen. I'm not saying it's good design, I'm just saying that once you allow animated underline offset distances, some designer is going to want to take it to the extreme.
• @jensimmons: people are going to animate this line
• @tantek: web designers will use overlines and underlines as alternative borders or alternative to outline-top and outline-bottom
• me: Could be used as an offset solid background too
• @tantek: graphical effects you can position without affecting layout

I agree with all of this. Also, text-decoration is decoration. It is not semantic. I do think overline and strikethrough should be offsettable too. So an author can adjust the position of a strike-through without having to change it to an underline. And so an author can use underline for colored lines/rectangles behind the text, and strike-throughs in front of the text.

[bradkemper]

I don’t know why we don’t just have text-decoration-offset instead of text-underline-offset.

[fantasai]

@bradkemper Because you generally don't want to offset each line by the same amount. :)

[jfkthame]

You could have text-decoration-offsets accepting three values, for underline offset, overline offset, and strikethrough offset. (Omitted trailing values would default to auto, if less than three are provided.)

[css-meeting-bot]

The CSS Working Group just discussed Limits on text-underline-offset to preserve semantic meaning, and agreed to the following:

• RESOLVED: always draw the underline even if it's spec to be outside a limit we choose

The full IRC log of that discussion

<dael> Topic: Limits on text-underline-offset to preserve semantic meaning

<dael> github: https://github.com/w3c/csswg-drafts/issues/4059#issuecomment-510148922

<dael> astearns: Discussed this, what, last week? Been more discussion in GH. jensimmons gave 3 options

<dael> astearns: 1. Don't do any clamping. 2. Wide clamp 3. Narrow clamp

<dael> astearns: Any additional information to add?

<dael> astearns: From my pov we shouldn't have a clamp at all. Whatever clamp we choose might be difficult to come at an interop consensus as to what it should be. I am not concerned with semantic implications of moving an underline.

<dael> astearns: Agree we should have these offsets for strikethrough and overline as well

<florian> +1 to astearns

<TabAtkins> 1

<dael> astearns: I think that's an arguement to add more offset properties and not clamping any

<dael> ??: I agree

<TabAtkins> +1, rather

<bradk> s/??/bradk

<fantasai> I'm against the narrow clamping definition.

<dael> florian: One nuance. If there are impl difficulties having an allowance for clamping for the reason of not painint many pages away I would accept that. Not go any further then that.

<dael> smfr: If you don't clamp do you allow underline to be clipped out? So UA must paint howeevr far or is it okay to not paint if it's "too far away". If you don't clamp need to say if can do clipping

<bradk> Ink overflow only.

<dael> florian: Do we expect impl to be more difficult to put underline 3000 px away?

<dael> smfr: More difficult for text decor

<dael> myles_: Performance hit where any part of page changes have to redraw entire paragragh

<dael> AmeliaBR: True for things like box shadows

<dael> myles_: Unfortunate there too

<dael> AmeliaBR: Shouldn't have special rules for this. SHould have general rule for at point you can reasonably clip

<dael> myles_: Have webcompat for others. THis is new so can change

<dael> jensimmons: Sounds to me this is an argument for a wide clamp. TO smfr point I meant any obstruction of author ability to put underline where they thought. A clip or a clamp is a level of sophestication we haven't reached.

<dael> florian: If you're going to limit it should be clamp rather then clipping.

<dael> florian: I would go for wide clamp or no clamp

<dael> Rossen_: Sounds like discussing merit of feature again. There was good consensus last time we wanted clamping

<dael> florian: no

<florian> I don't think there was emerging consensus

<dael> Rossen_: And also of the opinion that if we don't have clampping of offset then any other impl that do underline-offset will have fairly different semantic meanings as to where they'll draw underline or one that looks like a strikethrough.

<dael> Rossen_: For a new feature we have control over we have a chance to make it right.

<dael> Rossen_: If there are use cases to pay around with a background in the middle of the line box, use the striketrhough. If that's not good enough use a background. CHanging underline and allowing it to escape to be a strikethrough is bad from many PoV. Esp. for impl that don't have it. Having poor fallback is not a good idea

<jensimmons> q+

<dael> florian: I disagree it's poor. If you design an underline in such a way that it's thick and shifted up it's reasonable for the fallabck to be a normal underline. Argues for no local clamping. Wide is different.

<bradk> Strike though cannot be a background because it is in front of the text

<tantek> Why are underlines not drawn under the text (layerwise), so they can't actually strike-through? (they could strike-under?)

<dael> jensimmons: What I'm hearing Rossen_ is an argument for narrow clamp. I don't htink we've had consensus. After call esp hearing more and more no clamp. We can keep trying to articulate reasons, btu I haven't heard lack of consensus of the reasons for each. I've hear arguments as to why each is a good idea. I don't think there is consensus

<fantasai> tantek, they are drawn under the text

<florian> tantek: they are

<fantasai> tantek, and strike-throughs are drawn over

<florian> s/tantek:/tantek,/

<dael> jensimmons: Personally I prefer no clamp. Okay with wide clamp if it's for performance. narrow is much harder and we don't have to prevent authors from doing dumb things. We should pick which of the 3 and discuss details

<dael> myles_: Maybe comprimise is wide clamp. b/c wide spec can just recommend a general idea of where to put it.

<jensimmons> +1 for what Myels jsut said

<jensimmons> Myles just

<fantasai> s/Myels/Myles/

<dael> astearns: Another way of casting narrow vs wide is narrow is for semantic argument to keep underline and underline and not mistaken for anything else. Wide is for perfromance reasons but not semantic. Is that correct?

<dael> fantasai: yes

<dael> florian: That's how I understan

<tantek> thanks fantasai, then I'm not as worried about underline abuse, cosmetically, semantically or otherwise

<bradk> <u> is semantic. *-decoration is not

<florian> +1 to tantek and to bradk

<fantasai> Specific proposal for wide clamp: within the larger of 2 x max(line-box-height, font-height)

<dael> Rossen_: I think first is characterized well. Second is a little unfair. Impl will become more complex for unknown reasons. Performance will be potentially impacted. Having to go in and validate and keep validation out of current bounds for overflowing underlines is not great. I would say both impl and performance

<dael> astearns: To move discussion, can we resolve not to add a clamp to this property for mearly semantic reasons. Would anyone like to argue for narrow clamp to satisfy semantic concerns?

<fantasai> +1 to bradk

<dbaron> Implementations already need to keep track of underlines for overflow.

<tantek> I wonder if there are some math related display hacks we could do with underlines far from their text

<dael> Rossen_: I would be willing to continue to argue this. I would want to hear from other groups on this issue, including a11y

<dael> astearns: I wonder if makes sens eto break issue into 2 concerns. There are separate arguments for each.

<dael> astearns: Is there anyone besides Rossen_ who is up to argue for semantic concerns?

<tantek> this is still WD right? why not put the issue in the text as a question linking to the issue and leave the presence/absence of clamping open til we have more implementations?

<astearns> tantek: we are getting a second implementation now, so we can't punt

<fantasai> tantek, we have implementations

<dael> myles_: Our original purpose was this. THere's a diff between existing prop and this new property. You could never draw a text shadow and not move it. But you can draw an underline and not move it. Semantic is a11y but also if you view new website in old browser it will look totally different. I don't think that's a concern for existing css properties

<tantek> I feel like we can punt a bit longer until Chrome intents to implement, or have we seen that already?

<dael> fantasai: If you as an author want fallback for this underline to be no underline you can do that. If you want fallback to look regular you can do that. Both are possible

<dael> myles_: Authors have to think about that and add code

<dael> florian: To disappear yes

<dael> bradk: Have to think about that for any new

<dael> jensimmons: Fallback is natural and makes sense. If you're doing fancy in a new browser your fallback is a normal browser. I don't see it as complex, it seems natural from author PoV

<bradk> +1 jensimmons

<fantasai> s/browser/underline/ ?

<dael> astearns: On wide clamp side I'm a bit concerns about doing it right for new prop means we have a set that behave one way and a set behaving a different way.

<dael> astearns: That's a difficult story to tell

<dael> astearns: As we introduce more properties you have to keep in mind which do you clip and which do not

<dael> florian: A valid use case was brought up for not wide clamp. Since they're animatibe you can shift overline from way for to right position with the offset. I would expect people to try and do that. Yes perf implications and complexity but if you go for it you go for it. There's no good taste design law that says we should ban this

<dael> myles_: Seen websites that do that effect. All those have underline in a reasonable position through any point in animation. I think all 3 options would work on those sites. Sites I've seen move underline rfom 5 px below natural position to its natural position

<dael> florian: Not from outside screen?

<dael> myles_: Never seen a website that did that

<dael> jensimmons: I agree with myles. Don't have to worry about underline flying in from off page. Small move from hover is use case

<dael> jensimmons: I wonder if one thing to agree one is question of if we were to have a clamp are there people that want to clip and have it disappear or can we agree with will never clip. We'll clamp and it won't move anymore. You hit a limit and it no longer moves

<bradk> -1 to any clipping at all

<dael> AmeliaBR: I think it's important that if we allow clipping we have to be consistent where it happens so you don't have accidently disappearing. Clamping is easier to leave to UA discretion b/c will never have content disappear

<dael> myles_: Underline 700px away is effectively lost

<jensimmons> I disagree with what AmeliaBR just said. But she also changed the subject

<dael> AmeliaBR: Are we clipping at 700px or at 2em. We've been throwing a lot of things around.

<dael> myles_: 700px is the no clamp situation

<dael> astearns: jensimmons question is if we do agree on a limit do we agree underline will be drawn at that limit if author spec something outside limit.

<dael> astearns: I'm for resolving on always drawing underline

<dael> myles_: fine with that

<fantasai> I think if we resolve on always drawing the underline, whatever clamping limit we choose should be relatively close to the line

<dael> florian: Along lines AmeliaBR said we can make argument it's less important with strong interop. But I think it's better to always draw

<dael> bradk: can all agree on that

<dbaron> +1 to always drawing

<dael> astearns: And fantasai point that if we do decide to always draw limit will need to be fairly close. If we say always draw helps to define limit

<fantasai> because if the limit is ~ 700px, then the author might want to draw the underline off-screen but it'll only be off-screen on some UAs/some screen sizs

<dael> astearns: Obj to always draw the underline?

<dael> RESOLVED: always draw the underline even if it's spec to be outside a limit we choose

<dael> astearns: Remaining issue is do we have a limit. If we do what is it

<dael> astearns: I heard from some people they wanted to talk to other groups like a11y

<dael> fantasai: If clamping and not clipping we need to clamp relatively close. WIthin a couple of lines. If we allow anywhere on screen and UA limit is 1000px author will try for 9000px and on some monitors it's visible which is not intended.

<dael> fantasai: If we're clamping rather then clipping underline needs to show up in most cases

<dael> florian: You're aruging no clamp or mid-range clamp but not wide

<dael> jensimmons: I think she's arguing narrow or wide but not no clamp

<jensimmons> The problem fantasai just described already exists for authors.

<dael> fantasai: I'm against narrow; I agre with jensimmons and bradk arguments

<jensimmons> Authors putting things off-screen, thinking they are gone, when in fact they are on-screen for some people

<dael> bradk: If you're going to clamp position need to clamp thickness too. If top of underline is 3em away it can be 6em width

<dael> fantasai: It'll be visible enough for author to notice it's there. Interensting point if we want to allow underlines that are 500x width of line.

<dael> bradk: I'm for not restraining creative uses. It's a decoration. If there's a great reason to cover height of page, fine. If it's performance hit it's author's responsibility to deal

<tantek> +1 bradk

<florian> agree with bradk

<dael> astearns: I'm not hearing consensus. Some people interested in a limit for semantic, some people want a limit for impl difficulty or perf, and others not up for a limit at all.

<dael> fantasai: Straw poll?

<tantek> priorities: authoer > implementation > semantic purity

<dael> astearns: I suppose we can.

<dael> myles_: Fourth is allow impl to decide

<tantek> so I think we should lean towards bradk & jensimmons opinions here

<dael> fantasai: I think we need some interop. If one does semantic and the other does none it'll be bad for everybody

<bradk> Does it help to agree that it is an ink effect only, which doesn’t break to other pages and columns?

<florian> agreed with jen

<dael> jensimmons: If we land on narrow needs to be very specific. If we land on wide it can be more like the allowed zone needs to be something specific but beyond browsers can do what they want. Then you're out of author impact zone and into engineering impact zone.

<fantasai> bradk, we're already agreed on that, but good to remind

<dael> jensimmons: If it's about effecting authors need tight interop

<dael> Rossen_: Currently all browser clamp at semantic place. If you say differences are bad for everyone not having clamping close to semantic puts in that effect for everyone

<dael> AmeliaBR: Do we have more than one impl?

<dael> jensimmons: FF nightly and it has no clamp

<dael> Rossen_: All browsers that don't support offset draw underline at semantic height

<dael> astearns: Not relevent b/c discussing new property

<dael> Rossen_: Is based on amount of difference we impose on users without that property

<jensimmons> straw poll??

<dael> florian: THat's progress of enhancing. They do a sensible fallback

<dael> Rossen_: that's what I'm arguing about

<fantasai> s/progress of enhancing/called progressive enhancement/

<dael> astearns: I agree with myles_ and jensimmons there is a 4th optino of we have a wide clamp and we spec you must allow this much and where you decide liit is impl dependent

<myles_> *9:18

<dael> jensimmons: Can I suggest we don't do details in straw poll. It's no clamp, wide clamp, narrow clamp. We realize those might need to be refined and need allowance. THis is about what is important to people

<bradk> A

<dael> astearns: IRC straw poll. a. No clamp. b. Narrow Clamp. c. Wide clamp

<astearns> A

<florian> +1 to A, -1 to B, 0 to C

<jensimmons> A or C — no clamp or wide clamp

<dael> astearns: Please put in IRC, can vote for >1

<Rossen_> B, C

<tantek> A

<myles_> B C

<fantasai> C, A

<drousso> B C

<emilio> A

<dbaron> A or C

<nigel> +1 to A, 0 to B, -1 to C

<dael> astearns: About half of people on call have voted

<AmeliaBR> A

<smfr> A

<bradk> C would be OK if it is 1 meeeelion ems

<rachelandrew> A

<cbiesinger> A

<dael> florian: Surprised by nigel vote

<gregwhitworth> B, C

<dael> nigel: It seem slike underline is the thing that belongs near text. having a wide clamp doesn't seem helpful. If you're saying it can be 5 lines away from text but not 6 it seems arbitrary. Either the underline is associated to text and we enforce or we don't clamp it.

<melanierichards> B, C

<dael> florian: Narrow version of clamping tries to prevent overlapping underline with text so you can't mistake for a striketrhough

<fantasai> "Narrow clamp" forces the underline below the descenders and above the next line of text

<dael> nigel: May have misunderstood

<fantasai> "Wide clamp" has varying interpretations, but is not trying to make such a restriction.

<dael> florian: So you're for wide but not too wide?

<dael> nigel: Authors need to be able to overlapunderline with text. If it's a different color they can put text on top of it.

<dael> florian: So that means you disagree with what has been called narrow clamp.

<dael> nigel: Okay, I guess I should refine my vote.

<nigel> Revised vote: +1 to A, -1 to B, 0 to C

<dael> astearns: Looks like no clamp wins the straw poll, but wouldn't resolve on

<emilio> yes

<smfr> can live with C

<dael> fantasai: Question for people that voted a. Can you live with c?

<dael> florian: can

<dael> bradk: Can if it's sufficiently far

<dael> AmeliaBR: For every css prop we allow impl to have reasonable limits

<dael> bradk: 1mil em away doesn't matter

<tantek> yes the dr. evil option!

<rachelandrew> yes can live with C

<fantasai> Q - Limit is super-far, based on how big can you draw a box and things like that

<dael> fantasai: 3 ranges of clamping we could have. q: limit is super far based on how big can you draw a box.

<fantasai> R - Medium-range, like 6-10 lines - enough for author to notice that there's clamping, but not particularly restrictive

<dael> fantasai: r- medium range, like fixed to10 lines. lets author notice clampping, but not particularly restricted

<dael> Rossen_: Define in terms of line box?

<dael> Rossen_: I think that's more concrete

<dael> fantasai: That's what I'm talking about.

<fantasai> S - Short-range, 1-2 line boxes, tries to keep the line with the next, not overlapping the adjacent lines

<dael> fantasai: s- short range keeps line wiht text

<dael> Rossen_: q means no limits.

<dael> fantasai: I would equate q with basically no clampping. We've got medium and short range. Medium you can put it around but you can notice there's clamping. On screen most devices. Short is within range that gives author freedom within line box and slightly outside, but stay within range and avoid overlapping next text

<dael> fantasai: r and s are variations of [missed] clamp

<dael> fantasai: For people that voted a and can't live with r or s it means you can't live with c

<dael> jensimmons: Can you use medium and far words?

<bradk> -1 to R, -10 to S

<florian> voted for A, can live with all versions of C (but prefer further)

<dael> fantasai: Far is basically same as no clamp b/c based on memory usage. Equate with a. Wide clamping there's 2 approaches. One is a lot of room but clamp it close enough you can see there's a clamp. Or we pull tighter and say our goal is within range of line box and not too far down

<dael> astearns: For people that voted b and c is there anyone that could not live with a?

<dael> myles_: Totally confused with all the letters

<dael> a. No clamp. b. Narrow Clamp. c. Wide clamp

<dael> AmeliaBR: Everyone that said narrow also said wide. Maybe enough consensus with wide and then we get to what is wide clamp really mean.

<dael> s/ AmeliaBR / jensimmons

<bradk> A good compromise is when everyone is a little unhappy

<dael> jensimmons: I was thinking with a few line boxes away, I couldn't fine use cases to go any more then the line above it. I'm fine with it being +/- 1 line box. Doesn't get into not allowed above x height. It's much more forgiving, but it's like you don't want 2 line boxes away.

<dael> florian: I think bradk dislikes this.

<dael> astearns: I think it does improve discoverability of limit if we stop moving within a linebox of original position

<dael> myles_: Have we thought about moving other direction? We did clamp to not do striketrhough. Clamping moving toward text?

<dael> fantasai: This is all directions. This is in scope

<tantek> I'd like to allow authors to animate text-decorations into view from outside the viewing area

<dael> florian: That's option b

<tantek> that's my no-clamp use-case

<dael> astearns: We are at time. We'll come back to this again

[jensimmons]

We were just discussing the possibility (after looking at the straw poll taken during the CSSWG call) that maybe we could settle on the following:

We do have a clamp (and it is a clamp, where the underline is always shown, not a clip where the underline disappears — as resolved on the call). And the clamp is at +/1 one-line-box.

In this case, the word "neighborhood" is underlined. And that underline could actually be allowed as high up as the top of the line box above or as low as the line box below, but no further.

The idea is that....

• This would help browser engineers make sure performance wouldn't be a problem.
• This might help Authors who accidentally wrote bad code (saying 15em, when they meant 15px), by keeping the line from being unexpectedly far away.
• This would not limit the creativity of Authors, because there's not a reasonable use case for going any further out.
• This would help accessibility by not allowing nonsense choices.

Of course, there are reasons to go for a "narrow clamp" instead — but the straw poll shows a lot of people wanting "A: no clamp", and this might be a better compromise. Allowing creativity and avoiding too narrowly defining a limit, while still also providing a way to limit performance drains or deep confusion.

[frivoal]

https://github.com/w3c/csswg-drafts/issues/4059#issuecomment-512421819 seems like a good compromise to me. I'd prefer no limit at all, but I can live with that.

[astearns]

I'm still a no-limit partisan, but it's nice to have a specific example to work from.

I am assuming this would be based only on the current linebox height (or probably line-height, since linebox height is something that's not directly controllable by authors). Whether there is a line above and/or below and what their heights are wouldn't figure in.

In the picture, the yellow area is actually going about two heights above the initial position, and only one height below. If we're going with a limit, that would be fine - but we might want to allow two heights in both directions for symmetry.

If we do limit things based on line-height (or linebox height), there is an escape hatch authors can use for single lines of text - setting line-height to an absurdly large amount to make a larger offset available. I suppose that could be taken up by both sides (limits: look, for weird things you can work around it) (no-limits: whatever implementation benefits accrue from a limit can be subverted, so you still need to figure out how to handle it)

[astearns]

While several (but not all) of the people who voted for no limit did say they could live with some limit, when I asked the reverse I got no response. Is there anyone that prefers some kind of limit who could not live with a limitless offset?

[jfkthame]

I'm a no-limit partisan, too. :) (Aside from more general implementation limits a browser might have, such as the range of fixed-point dimensions.)

I don't think a clamp such as ±1 line really gains us much. It leaves plenty of scope for visually misleading effects, like an underline that looks like an overline, or one that appears to belong to the preceding or following line; and yet it does potentially impose limits on authors' creativity. I don't think CSS should do that without compelling reasons for it, and I don't see such reasons here.

For a silly example that uses a large offset, see https://jfkthame.github.io/test/anim-underline.html (requires latest Firefox Nightly and a couple of about:config settings, see info on the page).

[jensimmons]

To understand better what we are making, and the issues we've been discussing, I made another set of demos — this time ones that are more realistic to what Authors will do:
https://codepen.io/jensimmons/pen/voYMPE?editors=1100

I thought a lot about accessibility considerations as I worked on this, and realized there are already quite a few guidelines and best practices that should also be followed when styling underlines. Much of this is about choosing colors that work for the widest range of users — considering color contrast WCAG AA and AAA guidelines, and guidelines about text that goes over any kind of image. I don't see any need to add additional a11y guidelines to make sure text is readable because of color choices. That's already defined. Plus there are guidelines about underlines already in play — don't remove the line and then make the color difference between regular text and linked text too faint, for example. When I made the demo with a very thin hairline underline, I realized, oh, the same guidelines apply if I was instead removing the underline. Right. Don't make it too hard to see.

Perhaps folks who are making a11y linters and tests should add to their test suite, to consider underlines styles. That would likely help, and more and more of these tools pop up. But I didn't think of anything new for WCAG 2.

If anything, I think these styles will encourage Authors to do a better job at a11y, because they can _have_ an underline for a link, and make it 'pretty', instead of always removing it because they don't like how it looks.

Also I realized that the much more common accessibility consideration will have to do with line thickness, and color contrast. Especially with the new ability to let the underline go behind the text.

In our debates, the concern has centered on giving Authors too much leeway with offset — that they could put the underline in a place that's confusing. That is an accessibility consideration, but it's also a UX consideration in general. Putting the underline so far away that it's confusing to a person with low vision or a cognitive disability is going to be confusing to everyone.

[fantasai]

I am assuming this would be based only on the current linebox height

The line can move in some cases to accommodate descendant content, so we do want to use the line box height as part of the equation. Somewhat more precisely, I would define the limits as something like "from the middle of the line box the upper/lower limit is at max(line box height, font height)/2 + slack", where slack is whatever we'd like to decide, and at minimum should be (line-height - font-size)/2 to represent the other half of the line gap.

I do want to note that the offset position is measured from the top of the underline, however thick it is: zero places the entirety of the underline immediately below the alphabetic baseline (assuming text-underline-position: auto). If we add controls for strike-through and overline offsets, they'd be measured from the middle and bottom of the line thicknesses, respectively.

[jensimmons]

Jonathan Kew at Mozilla pointed something out to me that made me realize I think I've been misunderstanding what Safari's current implementation does. He said:

According to my testing, it's not exactly that negative values cause the underline to disappear, what's happening is that once the underline crosses the baseline of the text, skip-ink behavior kicks in and makes it disappear. If you make the offset so negative that it moves above the letters, it starts to appear again (skipping ascenders etc at first), and sometimes you'll see bits of it in between letters even when it's mostly hidden "behind" them.

I had thought Safari made the underline disappear for any offset value less than 0 — that the line was disappearing because it was being clipped. That's not the case.

Instead, this raises the point that without text-decoration-skip-ink: none the line does appear to get clipped. Safari needs to implement text-decoration-skip-ink: none to make the toolset complete. (And Firefox needs to implement text-decoration-skip-ink in general. We hope to do so as we implement the rest of these properties for styling underlines.)

I don't know that this realization affects the decision before us, but it's true that Authors will need to learn to always pair an explicit text-decoration-skip-ink: none every time the want to use text-underline-offset: [negative value] — or the line will seem to disappear, and that might be confusing. Apparently it was for me.

[jensimmons]

Learning that Safari doesn't already have a clip in place makes me lean even more to the no-limit camp. I'd personally prefer no limit at all.

I could live with a wide clamp, as drawn in https://github.com/w3c/csswg-drafts/issues/4059#issuecomment-512421819 (or something like it).

[jensimmons]

Actually, I can see that Safari does currently clamp.... I just updated this demo: https://codepen.io/jensimmons/pen/voYMPE?editors=1100#0 to include text-decoration-skip: none; /* for Safari */ so that skip-ink doesn't remove the underline, and we can see the clamp.

[jensimmons]

We need to resolve on this so that Firefox can ship in Firefox 70 (which merges Sept 2).

[jfkthame]

Actually, I can see that Safari does currently clamp.... I just updated this demo: https://codepen.io/jensimmons/pen/voYMPE?editors=1100#0 to include text-decoration-skip: none; /* for Safari */ so that skip-ink doesn't remove the underline, and we can see the clamp.

What version of Safari are you testing? Last time I tried Safari Tech Preview, it didn't appear to implement skip-ink:none control.

[litherum]

When we implemented underline skipping, the spec said the property was text-decoration-skip: ink. Since then, the text-decoration-skip property has expanded to multiple longhands, and we haven't had a chance to make the accompanying change in WebKit.

text-decoration-skip still exists, so there's no need for the /* for Safari */ part.

[css-meeting-bot]

The CSS Working Group just discussed Limits on text-underline-offset to preserve semantic meaning, and agreed to the following:

• RESOLVED: No limit. If past what the UA can render it's clipped

The full IRC log of that discussion

<dael> Topic: Limits on text-underline-offset to preserve semantic meaning

<dael> github: https://github.com/w3c/csswg-drafts/issues/4059

<dael> myles: Apple delegation has done internal soul searching and we're now comfortable with no limit solution. No clamping

<bradk> Yay!

<florian> yay

<dael> Rossen_: Is that only thing we wanted to resolve?

<jensimmons> Excellent!

<dael> myles: I believe that's the only topic of conversation

<dael> fantasai: There's going to be a limit because UA has limit of what it can do. If the spec size is greater then that should underline be clipped or clamped?

<dael> fantasai: Let's say limit is 5 pages long. Author expects underline on 6th page. Is the underline on the 5th page or not rendered?

<dael> myles: Match text shadow which I believe is clipping

<dael> fantasai: Makes sense. If you get > a couple pages clamping gets you unexpected lines

<dael> TabAtkins: I think if it's >a few lines it's confusing so clipping is fine

<dael> fantasai: Prop: no limit. If passed what UA can render it's clipped

<florian> +1

<dael> Rossen_: Okay.

<fantasai> s/passed/past/

<dael> Rossen_: I'm the biggest non-fan but won't object

<dael> Rossen_: Any objections or comments or can we resolve?

<dael> Rossen_: Objections?

<fantasai> s/lines/lines, which might overpaint something unexpected/

<dael> RESOLVED: No limit. If past what the UA can render it's clipped

[litherum]

I think this is already what the spec says, so I think this issue should just be closed.

[asmusf]

What about the consistency issue raised for treating overlline + strikethrough the same?

[litherum]

Test: https://github.com/web-platform-tests/wpt/pull/26033