[css-overflow][css-text-decor] should text-decoration include ellipsis?

[delan]

Given the following (demo), should the decorations extend to cover the “…” or “,,,”?

<style>
main {
    text-decoration: underline;
}
main > p {
    text-decoration: overline;
    overflow: hidden;
    white-space: nowrap;
    width: 3em;
}
</style>
<main>
    <p style='text-overflow: ellipsis;'>hello world</p>
    <p style='text-overflow: ",,,";'>hello world</p>
</main>

No known impl says yes, but I couldn’t find it specified anywhere in css-overflow or css-text-decor. @mrego thought it would be good to ask after seeing this code in Chromium:

  if (style.TextDecorationsInEffect() == TextDecoration::kNone ||
      // Ellipsis should not have text decorations. This is not defined, but
      // 4 impls do this.
      text_item.IsEllipsis()) {
    return absl::nullopt;
  }

[tabatkins]

My perhaps-naive assumption would be that it does apply; other text effects, like 'color', do.

[css-meeting-bot]

The CSS Working Group just discussed should text-decoration include ellipsis?.

The full IRC log of that discussion

<fremy> Topic: should text-decoration include ellipsis?
<astearns> github: https://github.com//issues/6531
<florian> q+
<fremy> fantasai: I have no strong opinion on this issue
<fremy> TabAtkins: The question is whether the text decoration should apply to the ellipsis dots
<fremy> TabAtkins: currently all implementations don't do it
<fremy> TabAtkins: but the dots use the font, color, etc of the text it replaces
<tantek> interesting that every implementation "missed it"
<fremy> TabAtkins: so this seems like a bug to me
<astearns> ack florian
<fremy> TabAtkins: but are there implementations where this would be difficult to do?
<PeterC> q+
<tantek> I’m curious if there's author consensus on this rather than reasoning from a spec/purity perspective
<fremy> florian: my intuition is similar
<fremy> florian: an issue is that the ellipsis is not supposed to be scrollable
<fremy> florian: so that makes it different from the rest of the text
<iank_> q+
<fremy> florian: because the text is located elsewhere
<fremy> florian: so it's a different line, not the same line
<fremy> TabAtkins: ah yes, if you have a wavy underline, the junction would be very undefined
<astearns> ack PeterC
<tantek> q?
<tantek> I'm not seeing any author input on the issue
<fremy> TabAtkins: so, this looks more like an abspos, which don't have text decoration inherit
<fremy> PeterC: from an implementation perspective, if the text is using a color font and the following characters might or might have had color characters
<fremy> PeterC: it's not clear what the implementation should do with the ellispsis
<astearns> ack iank_
<fremy> PeterC: but indeed that doesn't sound like easy case all the time
<fremy> iank_: I think the scrolling of ellipsis is not a requirement, it's a may
<fremy> iank_: we would likely object to a change to make normative
<tantek> q+ to say I’m a soft -1 on this, absent any author input/prefs on this, I’d rather NOT ask implementaitons to change something they happen to be interoperable on
<fremy> iank_: because we want to keep shaping
<fremy> iank_: so we would not want to make it an abspos
<astearns> ack tantek
<Zakim> tantek, you wanted to say I’m a soft -1 on this, absent any author input/prefs on this, I’d rather NOT ask implementaitons to change something they happen to be interoperable
<Zakim> ... on
<fremy> iank_: webkit does the same
<fremy> iank_: but not firefox, which does the abspos
<fremy> tantek: I haven't seen much request for it
<fremy> tantek: and we have interop now
<fremy> tantek: so maybe not changing is an option too
<fremy> astearns: ok, time is up, let's bring this back to the issue

[tabatkins]

@bfgeek During the call you objected to "ellipsis at paint time" (and thus, "keep the ellipsis in place as you scroll the content"), because Chromium does text shaping between the final text before the clip and the ellipsis itself. That isn't actually what the spec requires, tho, if I'm reading it correctly - it's allowed to do that shaping, and @frivoal was talking about just reshaping as different characters popped in as the "visual edge" of the overflowing content.

I understand, tho, that "invoke text-shaping during accelerated scrolling" isn't very viable, and the two current solutions (ellipsize once and scroll the text+ellipsis as a block, or spam the ellipsis as a paint-time effect over the content) are more amenable there.

[jfkthame]

A possibly-related question: should text-decoration apply to hyphens inserted at soft-hyphenation positions (whether via explicit ­ or auto-hyphenation)? It seems to me that soft-hyphen and ellipsis should probably have similar behavior in this regard.

Testing current browsers with

data:text/html,<p lang="en-US" style="width:5em;font:40px/2 serif;text-decoration:underline;text-decoration-style:wavy;-webkit-hyphens:auto;hyphens:auto;">supercalifragilistic expialidocious

indicates that:

• Firefox - does not extend the text-decoration to the hyphen glyph
• Safari - does extend the text-decoration to the hyphen glyph
• Chrome - does extend the text-decoration to the hyphen glyph, but with an ugly discontinuity

[tabatkins]

Possible complication there is that hyphens aren't responsive to scrolling, whereas the ellipsis is (per spec) intended to be. (At least, not accelerated scrolling; if you trigger layout changes such that text is re-laid out, that's a different story.)

(I think it's thus clear that the decoration should apply to the hyphen, as it's very straightforwardly Just Some Text.)

[jfkthame]

Agree that the scrolling issue is a difference.

However, it's less clear to me that a (soft) hyphen is Just Some Text and so necessarily carries the decoration. The hyphen is a transient rendering-time effect that arises just because of the particular context in which the text is being shown; it is not part of the textual data (most evidently in the case of auto-hyphenation, when there's not even ­ in the underlying data).

In that respect, it's very much like the ellipsis; neither of them are "present" in the text.

[bfgeek]

There are a lot of sutble interactions with now the spec is currently worded which aren't ideal in my opinion. (As a note - there are lots of shoulds in the section when its trying specify the scrolling behaviour - turning these shoulds into musts is what I'd object to).

• The appearing/disappearing of the ellipsis when the user is scrolling is a bad user experience IMO.
• The ellipsis in a scroller can also become disjoint from the actual content by a significant amount. (E.g. ellipsis is pinned to the inline-end edge, can be a significant distance from the content if there is a long ligature which is a bad user experience).
• As worded it is making an assumption about what types of fonts this will work correctly for. E.g. if there is a valid break opportunity within a word to place an ellipsis, a font might use a different ligature requiring a reshape.
• There may be other accelerated operations running which would affect this.

Its important to realize here also that the "overflow: scroll" case isn't how "text-overflow: ellipsis" is being used by authors. The primary case is the "overflow: hidden" case.

[tabatkins]

In that respect, it's very much like the ellipsis; neither of them are "present" in the text.

My point is that the hyphen is present as a direct result of, and integral to, text layout. The presence/location of the hyphen won't change for anything short of a text re-layout; as such, it has as much "solidity" on the page as literal text does. The ellipsis is, in some situations, opposed to that, where it can change its presence/location on things that don't otherwise cause text layout, such as scrolling.

Its important to realize here also that the "overflow: scroll" case isn't how "text-overflow: ellipsis" is being used by authors. The primary case is the "overflow: hidden" case.

Tongue-in-cheek counterpoint: marquee usage, for ellipsizing long song titles as they scroll back and forth automatically.

[bfgeek]

Tongue-in-cheek counterpoint: marquee usage, for ellipsizing long song titles as they scroll back and forth automatically.

Which are implemented with composited transform animations 😜 .