[css-ui] text-overflow: ellipsis when a word of different direction was truncated

[kojiishi]

When the overflowing word is in different direction from the paragraph direction, which part of the word should be truncated?

For example, if a paragraph in the logical order (uppercase means RTL characters):

abcdef ABCDEF

which is laid out this way:

abcdef FEDCBA

and if the last 3 characters overflows, should "FED" be visible, or "CBA"?

Test@jsbin

Blink/Gecko shows "FED..." while Edge/WebKit shows "CBA...". Blink w/LayoutNG currently matches to Edge/WebKit.

[frivoal]

From the spec:

L3:

[...] must hide characters [...] at the end edge of the line [...]

L4:

[...] must hide characters [...] at the applicable edge(s) of the line [...]

and

Ellipsing only affects rendering and must not affect layout

So old-Blink and Gecko are doing the correct thing here.

Also, UAs are supposed to (RFC2119 SHOULD) reveal more content when you scroll. This seems awkward to do with abcdef CBA.... As you scroll, you'd presumably get something like this

abcdef CBA…
bcdef DCBA…
cdef FEDCBA

which doesn't really feel like scrolling, since the right edge doesn't move. Compare with this what you get in Firefox on your example (changed from overflow:hidden to overflow:auto)

From an i18n point of view, the placement of the ellipsis to the right CBA is also weird. I think abcdef FED... makes sense since the ellipsis indicates that the rightmost part of the line was cut, and possibly abcdef ...CBA as well since it indicates that the middle of the line was cut (from a UI point of view it makes less sense), but abcdef CBA... is just weird : the missing part is (visually) between f and C but the ellipsis is shown next to A, which is confusing.

So again, in conclusion, old-Blink and Gecko are doing the correct thing here, and the other browsers should be fixed. Can you file the bug on Blink/layout-NG if there isn't one already? I'll fine the bug on everyone else.

We hadn't caught that scenario in the test suite, so I've just made a new test for it. Review appreciated.

[kojiishi]

Thank you for your prompt response.

Spec text-wise, the "end" was unclear to us whether it's logical (DOM order) or visual (after bidi reorder.) Some of us read it as logical, some as visual, hence the question.

Behavior-wise, I remember barely we discussed this before, or was that my wrong memory? Do you have pointers to minutes?

When my team discussed:

• Two of us think CBA is more natural, while one think FED is more natural.
• The CBA is consistent with overflow-wrap: break-word, while FED is consistent with overflow: hidden or clip.
• If we consider the line wraps, CBA is natural and consistent. If we consider the line doesn't wrap and go beyond the right end, FED is natural. Depends on which you assume, the other way is weird and confusing.
• In multi-line option [css-overflow] Consider support for multiple-line ellipsis #390, we probably want CBA due to above. /cc @bfgeek @tabatkins
• None of us in the discussion were bidi native.

Having minutes of WG discussion might help our understanding.

[tantek]

It's been years since @fantasai and I discussed this but yes, Gecko is doing what the spec expects. If there's some way to make the wording more clear, I'd be happy to consider that.

[frivoal]

@kojiishi I agree that multi-line ellipsis would be using the CBA, as it is effectively a matter of fragmentation, and that's what you would get if you were to break the line / fragment.

However, here we're talking about single line ellipsisis, which is a graphical thing that can be uncovered by scrolling, and explicitly does not affect layout.

If we consider the line doesn't wrap and go beyond the right end, FED is natural.

Indeed, that's what we consider, since:

1. you need to prevent the line from wrapping to get the effect anyway
2. when you scroll, you should reveal the hidden part

None of us in the discussion were bidi native.

That's certainly true of me as well, although my understanding is that the spec as it is written did have the input of bidi-native people (and got horizontal review from i18n)

[aphillips]

If you truncate visually, the text will be somewhat illegible. In addition, doing visual truncation will make text selection kind of broken (don't forget that other operations besides viewing can happen).

Instead of using non-words like ABCDEF, sometimes it's more helpful to use actual words in examples. If I used the sentence the world is full of ZEBRAS, ELEPHANTS, and OSTRICHES and then have overflow, it makes more sense (you might guess what the word is) if I used logical truncation:

the world is full of ZEBRAS, ELEPH...

While having it be:

the world is full of ZEBRAS, HANTS...

... doesn't make any sense.

[matial]

In the example presented by Aphilips above, a more realistic representation of what is displayed should be (assuming that "and OSTRICHES" overflows to the next line):

Logical truncation:
the world is full of ...HPELE ,SARBEZ

Visual truncation:
the world is full of STNAHPELE ,SA...

Personally, I don't have a strong preference either way.

[frivoal]

@aphillips In the non bidi case, the words are truncated visually: pointer events are expected to hit the elements behind the ellipsis when you click on the ellipsis, selecting the ellipsis and copying to the clipboard gives you the elided text, you are supposed to be able to scroll (if overflow is scroll or auto) to reveal the part that has been hidden...

Consider also that CSS-UI-4 introduces a fadeout style, in addition to the existing "...".

I don't know how to make that all these things work or make sense if we truncate other than visually.

[kojiishi]

@tantek Thanks for the clarification. Put "what it should be" aside, I understood past discussions and the spec intention now.

For the text, Blink team uses terms "logical" and "visual", the former is DOM order and the latter is the order after bidi reorder, but I don't think this distinction is well-defined in CSS nor in HTML specs yet. There's no other features that handles grapheme cluster boundaries after bidi reorder AFAIK, so you probably need to define it.

Also, when you say "end" side, there are 4 different directions for a character; block, paragraph, inline, and resolved. I guess you want paragraph here (haven't tested block/paragraph but tested no browsers use inline nor resolved.)

[kojiishi]

@frivoal

Thanks for the explanations.

I agree that multi-line ellipsis would be using the CBA...

I wasn't clear enough, sorry about that. I think there were 2 different points in our thinking:

1. What was the spec intention, and the motivation for the intention.
2. When multi-line ellipsis is coming up, I think both implementers and authors want consistency between single-line option and multi-line option set to # of lines to 1.

Point 1 is clear now, thank you for that. What do you think about point 2? I think even with fadeout style, if the following text is assumed to be in the following lines, CBA makes sense.

Is the consistency with multi-line option considered as a new data to reconsider the past conclusion?