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

Summary

The following is a summary of
https://bugzilla.mozilla.org/show_bug.cgi?id=883884, which has become a
spec issue.

Currently, as implemented in Mozilla, when text-overflow:ellipsis and
text-overflow:<string> truncate bidirectional text, and the truncation
point falls in an opposite-direction phrase (e.g. in the middle of an
English phrase embedded in Hebrew text or vice-versa), the logical *end* of
the opposite-direction phrase is shown, not the logical beginning. This
simply isn't useful, since the end of the opposite-direction phrase is not
likely to make much sense without the beginning.

For example, try the following URL in Mozilla:

data:text/html,<html dir=rtl><div style="white-space:pre; overflow:hidden;
text-overflow:ellipsis; width:250px;"><bdo dir=rtl>HE SAID</bdo>: i will be
home by 8, come hell or high water</div></html>

On the other hand, WebKit, Blink and IE (or, at least IE9) show the logical
beginning of the opposite-direction phrase (for text-overflow:ellipsis;
they do not implement text-overflow:<string>). Try the same URL there.

This logical (as opposed to Mozilla's visual) truncation is useful, and I
want the spec (http://dev.w3.org/csswg/css-ui/#text-overflow, which
currently isn't very clear on this) changed to mandate it. In a nutshell, I
think it should say that text-overflow:ellipsis and text-overflow:<string>
display the maximal logical prefix of the content (on a grapheme cluster
boundary) that fits completely in the available width.

However, as pointed out by Robert O'Callahan, logical truncation breaks
down when the element has overflow-x:scroll or auto, and, in fact,
scrolling a text-overflow:ellipsis element is badly broken in Blink, Webkit
and IE.

At first glance, the utility of combining text-overflow:ellipsis with
overflow:scroll (or auto) seems questionable. The point of the ellipsis is
to indicate to the user that there is more stuff that they can't see. But
the scrollbar itself indicates the same thing, so why would one want to
have both a scrollbar and an ellipsis? Nevertheless, Robert points out that
since scrollbars "disappear" on the Mac and most touch devices until one
tries to scroll the content, having an ellipsis to indicate scrollable
overflow can actually be useful. Thus, we do want text-overflow:ellipsis to
work well with a horizontally scrollable element.

To do that, we could specify that text-overflow:ellipsis and
text-overflow:<string> will works visually when combined with
overflow-x:scroll or overflow-x:auto. After all, scrolling is inherently
visual, and the bidi problem does not exist when the element is scrollable,
since the user can see the missing content by actually scrolling. For other
values of overflow-x, however, text-overflow:ellipsis and
text-overflow:<string> should work logically, as described above.

There is still a bit of a problem in that an element can be scrollable in
some situations despite being "overflow:hidden", e.g. when it's
contenteditable, or when there is a script manipulating its
scrollLeft/scrollTop. The latter approach is often used by pages that
implement their own scrolling UI mechanisms (e.g. custom scrollbars). Such
an element would need text-overflow:ellipsis to work visually, but will
have it working logically (and thus breaking) instead. I am not really sure
what to do about that. Perhaps we need a new value for overflow,
"custom-scroll", which would behave like "hidden", but indicate that
scrolling is being allowed by custom means.

Robert also pointed out that  logical truncation results in a confusing
visual location for the ellipsis. For example, take "HE SAID: i will be
home by 8" logically truncated after the "be". Blink/WebKit/IE currently
display it as:

...i will be :DIAS EH

This is confusing because the ellipsis does not appear where text has been
elided ; the ellipsis is supposed to represent the missing text, after all.

I say that the level of confusion is not really the main point here. Bidi
text is confusing by its very nature. But visual truncation of bidi text is
not just confusing - it simply isn't useful, as explained above.

Nevertheless, if we are already talking about the ellipsis location, I
think that the alternative ellipisis location is in fact a better choice:

i will be... :DIAS EH

This is in fact the way bidi suggestions are ellipsized in Chrome's Omnibox
suggest dropdown, by design. (The Omnibox is not implemented in HTML/CSS.)
This was the unanimous choice of several bidi experts in internal
discussions on the subject. (Visual truncation was also considered and
quickly rejected.)

This visual location of the ellipsis can be obtained simply by appending an
LRM or RLM after the ellipsis, LRM if the bidi level of the last character
before the ellipsis is even, and RLM if it's odd.

Aharon

Received on Monday, 24 June 2013 09:05:32 UTC