Re: [css3-ui] questioning "ellipsis may occur at a text wrap opportunity" (Issue 76)

On Sun, Feb 1, 2015 at 3:30 PM, Florian Rivoal <florian@rivoal.net> wrote:
> (https://wiki.csswg.org/spec/css3-ui?&#issue-76)
>
> This was recently added to the spec:
>
> "Implementations may ellipse at a text wrap opportunity that occurs before a character boundary where an ellipsis is required."
>
> I believe this was meant to address this issue raised via twitter, recorded as https://www.w3.org/wiki/CSS3-UI#Issue_54
>
> https://twitter.com/sil/status/537627213789949952
>
> I am not convinced it is a good idea, at least not without more details.
>
> 1) While it can produce better results in some cases (for example, the one in the tweet), it can produce worse results in other cases. For example, if the line it's being applied to is
> "It's Supercalifragilisticexpialidocious"
> you'd want
> "It's Supercalifragilisti..."
> not
> "It's..."
>
> You could argue this is a quality of implementation issue and a sufficiently smart UA would only apply this MAY in cases like the tweet, and not on Mary Poppins' lyrics, but while I am ok with quality of implementation differences when it comes to things being more or less pretty, it feels less appropriate when it can cause (too much) text to become invisible.
>
> 2) When scrolling through the elided text, removing / revealing one character at a time gives a fairly smooth and intuitive result. If entire words appear and disappear at once, you may have to scroll quite a bit before revealing any new content, possibly misleading users into believing that scrolling does not reveal the remaining content, and giving up before seeing it.
>
> If this is meant to be symmetric, and apply on the start side when when using the 2 value syntax, the scrolling the experience would probably be even worse. Whole words disappearing from the start side of the line as you scroll forward would make for a very jumpy experience.
>
> 3) Depending on how "before" in this new sentence is interpreted, it may not play well with bidi text of mixed directionality. text-overflow: ellipsis, per spec, removes characters from the end of the line. In a line with mixed bidi text, wrapping can happen in the middle of the line rather than its end, so applying line breaking algorithm to find the place from where you can insert the ellipsis would lead to incorrect results. We really want to remove characters from the end of the line, so that they can be revealed when you scroll.
>
> This example (loaded in Firefox, other browsers don't behave well here) shows a good behavior http://jsbin.com/yequweregu/1/edit
>
> We could clarify the sentence to make clear that "a text wrap opportunity that occurs before a character boundary" is meant to be interpreted in the physical sense causing (in that example) the rightmost hebrew word(s) to be elided. I don't know if UAs still have info about what's a text wrap opportunity once they're at that stage though. Or we could say that UAs must not do this in lines with mixed directionality.
>
>
> Overall though, given that these complications, I'm more tempted to drop this entirely.

Per F2F discussion, it appears we want to keep this, and leave the
potential complications to browsers as a QoI issue.  Some browsers
already do ellipsize at wrap opportunities in some cases.

~TJ

Received on Thursday, 19 February 2015 16:41:20 UTC