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

Although I agree with most of what Aharon wrote (see note attached below), I am not so sure about the preferred location of the ellipsis.

 

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?

Let 's take Aharon's example, slightly modified. The displayed part is "HE SAID I will be home". The following text might be  " by 8", in which case it may make sense to show the ellipsis on the right of "home".

However the following text could be "AND LEFT", in which case it is better to show the ellipsis on the left side of the whole string.

 

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.

A use case is a mail agent (MS Outlook can serve as example) with a list of subjects displayed in a column, some of them ending in an ellipsis when the column width is too narrow for the text. Having the ellipses appear at various places in the subject lines is neither esthetic nor  optimally informative, IMHO.

 

--

Shalom (Regards),  Mati

 

From: Aharon (Vladimir) Lanin [mailto:aharon@google.com] 
Sent: Tuesday, June 25, 2013 3:52 PM
To: W3C style mailing list; public-i18n-bidi@w3.org; www-international@w3.org
Subject: Re: text-overflow:ellipsis and text-overflow:<string> need to truncate bidi text logically

 

Cross-posting to public-i18n-bidi@ and www-international@; I left them off my original post by mistake.

 

On Mon, Jun 24, 2013 at 12:04 PM, Aharon (Vladimir) Lanin <aharon@google.com> wrote:

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 Wednesday, 26 June 2013 06:39:00 UTC