Re: text-overflow:ellipsis and text-overflow:<string> need to truncate bidi text logically

On Mon, Jun 24, 2013 at 7:08 PM, Tab Atkins Jr. <jackalmage@gmail.com>
 wrote:

> We had this exact discussion some time ago, and decided very
> deliberately that we wanted the ellipsis to be a visual effect, not a
> logical one.  I'd recommend searching the mailing lists for these
> discussions first, so you can see the older arguments for it.
>

Here are the arguments for visual truncation that I've been able to find,
primarily in the Minutes and Resolutions from the F2F at TPAC
2009-11-02<http://lists.w3.org/Archives/Public/www-style/2009Nov/0219.html>.
As far as i can see, there has been very little actual discussion of the
pros and cons on www-style itself. There was some discussion in 2011, but
it seemed to concentrate on what exactly is the behavior of different
browsers, not on the pros and cons of different options.

- Visual truncation is easier to implement.

Perhaps. But it does not mean that visual truncation gives good-enough
results for bidi text, and implementing the wrong thing cheaply does not
sound like the right decision. Nor does it mean that implementing logical
truncation (I mean without major bugs) in a scroll-less element has to be
prohibitively expensive. Conceptually and computationally, logical
truncation should be very similar to wrapping, and should be no more
difficult to implement. When the line can't hold any more content, instead
of wrapping, one truncates. The major difference is that the calculation of
whether we have run out of room needs to take the width of the ellipsis in
mind. And, of course, as currently spec'ed, the truncation for ellipsis can
happen in the middle of a word - although it would actually be a lot more
useful to truncate on a word boundary, exactly as in wrapping.

- Logical truncation does not seem to be compatible with scrolling.

I agree. Nor is logical truncation needed when the user can scroll the
content, and so I am proposing doing it only for elements with
overflow-x:hidden. Other elements should indeed get visual truncation.

- Visual truncation is "easier to understand".

I am not sure what specifically was judged to be more difficult to
understand about logical truncation. If it is the location of the ellipsis
(see below), it can be addressed.

IMO, visual truncation is not so easy to understand either. Yes, a savvy
user should realize that what they are seeing is a visual truncation,
similar to the visual clipping with which they are familiar from scrolling
etc. But I don't think that a not-so-savvy user will get that.

And even for the savvy user, being able to understand what has happened is
very difficult from liking it. Yes, when I see that my laptop is suddenly
shutting down of its own volition, i *understand* that it has probably run
out of power. That does not mean that I *like* it. And I do not think that
being able to see a random, non-contiguous bit of opposite-direction text
before the ellipsis, with no way to get the part that came before it is
very useful, so I have no reason to like it.

- Placing the ellipsis at the visual overflow boundary while truncating the
text logically puts the ellipsis far away from the truncated text (in the
bidi case).

I do agree that this placement of the ellipsis is somewhat confusing, and I
would prefer it to be placed at the truncation point. But others (e.g.
Mati) seem to prefer the other location. Either way, the maximum damage
that the wrong choice for the ellipsis location will do is confuse the
user. As I said above, I consider that to be of secondary importance to
giving a more useful result.

- WebKit and Blink do weird stuff when truncating text containing inline
boxes.

This is just a bug. I don't think that it even confirms that logical
truncation is seriously difficult to implement. IE does *not *have this
problem.


On Wed, Jun 26, 2013 at 9:38 AM, Matitiahu Allouche <
matitiahu.allouche@gmail.com> wrote:

> As I understand it, the ellipsis hints that more text would appear in its
> place if there was enough display room. But can we be sure that the hidden
> text has the same direction as the last part of the displayed text?
>

I think that the way to do the ellipsis is as follows:
- Find the first character to be truncated, i.e. the first one logically
that will not appear. This should never be be an explicit directional
formatting character (LRE, RLE. PDF, etc.), since they are zero-width.

- Replace that character with the ellipsis (putting it in a directional
isolate if it is a custom string, as opposed to the bidi-neutral ellipsis
character itself).

- Append an LRM if the bidi level of the replaced character was even, and
an RLM otherwise.

This will make sure to put the ellipsis exactly where the first truncated
character would have gone.

BTW, in this approach, it only makes sense to give the ellipsis the same
style as the first truncated character.

Another consideration is how easily can the user spot the ellipsis and know
> that some text is missing. I think that it is more obvious if the ellipsis
> is at the edge of the displayed text and not somewhere in the middle.
>

True. However, in most cases, the user only really cares to know whether
some text is missing if the user has bothered to read the text that's there
to the end. And if that is the case, the user will end up at the ellipsis
anyway.