[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?

[aphillips]

@frivoal A case could be made that the non-bidi case (that is, the unidirectional case) isn't necessarily truncating "visually", it just looks that way :-). Consider a purely right-to-left text: it should truncate on the left side rather than the right side.

@kojiishi calls out that vertical presentation is also affected here and needs an answer about visual vs. logical truncation. I think that shouldn't be overlooked.

If the control is a "viewport" on an infinite baseline of text, that suggests a visual presentation (visual is certainly easier in that case; particularly I'm thinking about scrolling behavior, although cursor movement might be an adventure if the cursor is placed in bidi text---the cursor normally moves logically in text)

@matial I actually treated mentally each RTL word as isolated (as we recommend for insertion), as they are inserted into an LTR context, so logical:

the world is full of SARBEZ, HPELE ...

And visual:

the world is full of SARBEZ, STNAH ...

[ntounsi]

Which part of the word, ABC or DEF, is truncated is relative and depends on base direction (and the reading direction).

With Firefox:

In RTL mode, Arabic "FEDCBA" will result in "...CBA". The right reading for Arabic readers
The Latin "abcdef" will result in "...def".
Scrolling goes from right to left showing the rest of the text.

In LTR mode it is just the opposite behavior

Arabic "FEDCBA" will result in "FED ...".
The Latin "abcdef" will result in "abc...". The right reading for Latin readers
Scrolling goes from left to right showing the rest of the text.

So, ellipsis is coherent with scrolling.

I expect this is the right thing to do.

Give it a try here with this text "abc def ابجد هوز" and the style text-overflow: ellipsis; and overflow: scroll; to see how the text is cut and scrolled.

[frivoal]

@frivoal A case could be made that the non-bidi case (that is, the unidirectional case) isn't necessarily truncating "visually", it just looks that way :-)

I you just look at it, a case could be made (although I would still disagree). Once you start looking at user interaction or how to integrate with other parts of css, I think the case for non-visual ellipsis falls apart (or at least gets substantively more complicated).

1. What do you get into the clipboard if you copy when the selection is as indicated in the following example abcdef C[BA...]? Or should it be impossible to make such a selection and instead have abcdef |CB]A[...|. There's no such ambiguity/difficulty with abcdef F[ED...].

2. What element gets the click even when you click on the ellipsis if the ellipsis isn't visually? The click is supposed to go to the element underneath the …, but if you're doing this logically, this is not defined what is there.

3. What happens when you scroll?

4. Say you have an abspos anchored between B and C, and another one between E and F. Where do they go if you do this logically instead of visually when 3 letters are ellided? When happens when you scroll? I have not tried Blink/layoutNG (how can I get my hands on that?), but in Safari, this results in the abspos being at the same place as if you were dong this visually, but with the text becoming abcdef FB…. Which is surely not what anyone would want. http://jsbin.com/ririwoj/4/edit?html,css,output Maybe Blink/LayoutNG is better, but I'd expect anything not based on the visual order to have issues.

5. Also, consider the case of text-overflow: clip. When abcdef FEDCBA overflows the the box, the web shows abcdef FED not abcdef CBA (we are speaking of overflow here, not wrapping, if nothing overflows, text-overflow does nothing). text-overflow is there to allow authors to add in a visual indicator that the text is being truncated due to overflowing. It would seem wrong to me that doing so would cause previously hidden text to be shown and previously shown text to be hidden instead.

6. Movements of the caret and extension of the selection with shift+arrow in this situation would also be well defined with visual ordering: the caret/selection goes wherever it would go if there was no ellipsis (and scrolling occurs accordingly). With visual ellipsis, the model is not defined.

EDIT: added point 7
7. The spec says "Ellipsing occurs after relative positioning and other graphical transformations. " That sounds like a weird / difficult thing to do if working non-visually.
END-EDIT

TL;DR: this is handling of overflow, not of wrapping. Treating it as wrapping makes everything complicated, treating it as overflow makes everything fall out of existing behavior.

Consider a purely right-to-left text: it should truncate on the left side rather than the right side.

This has been considered, and is why the spec say you put the ellipsis at the end of the line, not at the right of the line.

@kojiishi calls out that vertical presentation is also affected here and needs an answer about visual vs. logical truncation. I think that shouldn't be overlooked.

It isn't overlooked, and is also handled by using the end edge of the line.

---

I absolutely want to do the right thing here for internationalization, but this isn't like this is a new proposal that hasn't been defined precisely yet. The current definition of doing it visually dates to 2011, and the decision was made because of bidi (as explicitely recorded in the commit message, in order to be able to support interaction sensibly in the face of mixed directionality). This has been in css-ui specs for 7 years, and was in css-text for 3 years priori to that.

I encourage you to look at how the whole feature is defined in the spec, and how it is extended in level 4 (that text has matured over many years too).

The spec went through 2 CRs and associated horizontal reviews with this feature in it, and has now reached PR.

It is possible that a superior model exists, but the way it is defined is deliberate, and it forms a consistent system. It is never too late to fix a broken spec, but I think at this stage If you'd like to replace it, we need substantial evidence that the current design is broken or suboptimal, and we'll need to see the full picture of how the alternative would work, not just visually, but also in terms of layout, interaction, etc.

[frivoal]

Also, when you say "end" side, there are 4 different directions for a character

The wordings used in the spec are:

end line box edge in the inline progression direction of its block container element

and

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

Per https://www.w3.org/TR/css-writing-modes-3/#end, I do not believe this to be ambiguous.

[frivoal]

example with actual RTL text (thanks @ntounsi ) http://jsbin.com/lidijin/1/edit?html,css,output
Firefox is sane, Safari is not.

[kojiishi]

Minor, but "end line box edge in the inline progression direction of its block container element" and "the end edge of the line" are not always the same. It looks like impls agree to use the former, disregards the direction of the line box, from this test.

For logical v.s. visual, I see both have reasonable justifications, both have supporting people, and both have 2 impls. I guess it's best to see how our discussion goes on #390 Consider support for multiple-line ellipsis and #1574 Consider support for ellipsizing only whole words.

[kojiishi]

Thank you @frivoal for the history, that's definitely something we should keep in mind. This is about an edge case that we can probably change without causing web compat problem, but if it's questionable, we can help to gather data.

[frivoal]

This is about an edge case that we can probably change without causing web compat problem.

Please explain how you position abspos descendants, how you do scrolling, how you target pointer events, how you handle clipboard and selections, whether you plan to do the same for overflow:clip (and if not, why not), how you handle caret position if the element is editable...

Maybe there are good answers to these questions, but I have not hear them yet.

If there's no answer to these questions, it seems to me that this is an implementation shortcut leading to bugs, not a reasonable alternative solution.

[frivoal]

see how our discussion goes on #390

This is unrelated. Both topics use the “…” character, but apply in very different situations. This is about overflowing a non wrappable line in the inline direction, that is about cutting wrapped content that overflows in the block direction (aka fragmentation).

#1574 Consider support for ellipsizing only whole words

I don't see why this would require switching to the logical ordering. Yes, this is more than a purely graphical operation, and you need to be aware of character boundaries, word boundaries, etc, but it still makes sense to work after bidi reordering, after transforms, etc.

[fantasai]

The spec writes

For the ellipsis value implementations must hide characters and atomic inline-level elements at the end edge of the line as necessary to fit the ellipsis, and place the ellipsis immediately adjacent to the end edge of the remaining inline content.

I think the “end edge of the line” is very clearly not about the DOM order of characters. As @tantek says, the clipping is visual only. There were in fact very long discussions about this in the CSSWG, and we resolved very clearly to have this behavior. Altogether the text-overflow property is supposed to be a paint-time effect, not a layout-time effect. This was not only because it is easier to specify and implement, but because the effect is more consistent.

As for multi-line ellipsis, the text that is clipped is on later lines, and line-breaking is already logical, so there is no conflict with expectations there: later text on later lines is elided.

@tantek Can you add a bidi example after the quoted text, please?

[FremyCompany]

FYI, a future version of Edge will comply with this:

[aphillips]

The I18N WG discussed this in our teleconference of 18 January 2018 and I was actioned with this reply.

The WG members present felt that the arguments in favor of visual truncation are persuasive. In particular, we agree with @fantasai's comment just above.

[fantasai]

@FremyCompany Great example! Numbers in RTL languages are still LTR--logical truncation with the ellipsis on the end-edge of the line would create much more confusion about what part of the number is visible/missing than visual truncation, imho.

[frivoal]

Made web-platform-tests/wpt#9294 based on @FremyCompany 's example. @FremyCompany, @fantasai Wanna review it? Should be a quick & easy one.

[frivoal]

Oops. I had already written a test for that, and forgot about it. Maybe there's something to be said for quick reviews...
Anyway, the tests are subtlety different, so maybe they're all good to have.
web-platform-tests/wpt#9294
web-platform-tests/wpt#8780