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 Tuesday, 25 June 2013 12:52:54 UTC