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

> @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.,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.

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 <a href="">commit message</a>, 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.

GitHub Notification of comment by frivoal
Please view or discuss this issue at using your GitHub account

Received on Tuesday, 9 January 2018 09:47:46 UTC