Open delan opened 3 years ago
My perhaps-naive assumption would be that it does apply; other text effects, like 'color', do.
The CSS Working Group just discussed should text-decoration include ellipsis?
.
@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.
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:
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.)
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.
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).
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.
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.
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 😜 .
Given the following (demo), should the decorations extend to cover the “…” or “,,,”?
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: