- From: Aharon (Vladimir) Lanin <aharon@google.com>
- Date: Tue, 25 Jun 2013 15:52:03 +0300
- To: W3C style mailing list <www-style@w3.org>, "public-i18n-bidi@w3.org" <public-i18n-bidi@w3.org>, "www-international@w3.org" <www-international@w3.org>
- Message-ID: <CA+FsOYYwOvPNLS+XnayP5W0dR+7Sdk9ADkkv+wPNVCNwOB5AjA@mail.gmail.com>
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:51 UTC