Open Bug 883884 Opened 11 years ago Updated 2 years ago

[RTL] text-overflow:ellipsis and text-overflow:<string> work incorrectly for bidi text

Categories

(Core :: CSS Parsing and Computation, defect)

defect

Tracking

()

Iteration:
42.1 - Jul 13

People

(Reporter: aharon, Unassigned)

References

(Blocks 1 open bug)

Details

Attachments

(2 files)

Attached file test case
Currently, 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 is not useful, since the end of the opposite-direction phrase is not likely to make any sense without the beginning. Nor is it interoperable: WebKit, Blink, and IE show the logical beginning of the opposite-direction phrase (for text-overflow:ellipsis; they do not implement text-overflow:<string>).

In a nutshell, text-overflow:ellipsis and text-overflow:<string> should  display the maximal logical prefix of the content (on a grapheme cluster boundary) that fits completely in the available width.
There was a good bit of discussion about this on the list, as I recall.  What was the conclusion?
Attachment #763588 - Attachment mime type: text/plain → text/html
Unfortunately the discussion that resolved this issue didn't happen on a public mailing list (AFAIK; I may have missed some of the public discussion). The spec says to clip visually like we do, although it's not 100% clear:
http://dev.w3.org/csswg/css-ui/#text-overflow
"Ellipsing only affects rendering and must not affect layout nor dispatching of pointer events." Showing the logical beginning repositions characters and would affect layout.

A problem with logical clipping is that it breaks down when the element is overflow:scroll or auto. text-overflow and scrolling are still completely broken in Blink/Webkit, so it's hard to demonstrate in Chrome, but consider visual clipping on an example like yours but scrollable. Let's say the DOM is <div dir="rtl" style="overflow:scroll; white-space:pre; text-overflow:ellipsis">abcdefghijklmnopqrstuvwxyz HEBREW</div>.

Then initially you get:
...abcde WERBEH

Now, even without scrolling this is already quite confusing in Chrome because the ellipsis does not appear where text has been elided --- the ellipsis is supposed to represent the missing text, after all. The ellipsis could be displayed in the middle of the line:
abcde... WERBEH
But I think that would also be confusing, just in a different way.

Anyway, assuming the ellipsis stays at the block boundary, what happens if you scroll left?
...abcdefgh WER

So this is weird ... the user is scrolling, but the Latin text isn't moving! What if you scroll the Hebrew text completely out of view? I'm not sure, but let's assume
...defghijklmno
Now as you scroll left, new text comes into view on the right and the text moves left. It's freaky. Now imagine you're using a touch-and-drag interface to do this. And imagine specifying this. And remember you're not just reordering and repositioning text, but any inline elements in that text, including say <video>.
> [with logical clipping] initially you get:
> ...abcde WERBEH
> Now, even without scrolling this is already quite confusing in Chrome because
> the ellipsis does not appear where text has been elided --- the ellipsis is
> supposed to represent the missing text, after all. The ellipsis could be
> displayed in the middle of the line:
> abcde... WERBEH
> But I think that would also be confusing, just in a different way.

I agree that both options are confusing, but one of them *is* better. A couple of years ago, an internal discussion took place between several bidi experts at Google (you would recognize a couple of the names) in the context of ellipsizing bidi suggestions in the Chrome omnibox suggest dropdown. Since this is not implemented in HTML/CSS, the behavior of text-overflow:ellipsis in various browsers was only a reference point, not the focus of the discussion, and all options were considered. A unanimous conclusion was reached not only in favor of logical clipping, but in favor of putting the ellipsis at the clipped phrase's directional end (which can be in the middle of the line), and that is the way it is actually implemented in the omnibox. I am considering filing a bug on Chrome that they should do the same for text-overflow:ellipsis.

In any case, the level of confusion is not really the main point here. Bidi text is confusing by its very nature, even without clipping or scrolling or anything. The point is that visual clipping of bidi text is not just confusing - it simply isn't useful. The logical tail end of the opposite-direction text that it does show is usually incomprehensible without its beginning, so you might as well not show the opposite-direction part at all. The use of visual clipping (without text-overflow:ellipsis) of the message snippet in the thread list view in Gmail is one of its worst bidi problems and is well-known as such.

> A problem with logical clipping is that it breaks down when the element is
> overflow:scroll or auto.

I simply do not understand the utility of combining text-overflow:ellipsis with overflow:scroll (or auto), even without bidi. 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 you want to have both a scrollbar and an ellipsis? And the user *can* see it, by moving the scrollbar. I think that text-overflow should only be taken into consideration when overflow is hidden.

BTW, Mozilla's (or probably the current CSS spec's) treatment of the conjunction text-overflow:ellipsis with overflow:scroll is internally inconsistent. If for some strange reason one does want an ellipsis to indicate that stuff got clipped despite the presence of the scrollbar, then why just have it at one end? If you've scrolled the text into its middle position, you should really be showing an ellipsis at both ends.

Note that (as far as I can tell from searching the Mozilla Bugzilla) no one is complaining about this lack of consistency. Similarly, no one has filed a bug on WebKit's or Chrome's admittedly silly treatment of this conjunction. The lack of all these bug reports indicates to me that this conjunction simply isn't useful.

So, what *should* happen when someone does specify both text-overflow:ellipsis and overflow:scroll (or auto)? If you find the WebKit/Blink/IE treatment of it too silly, you could just treat it as if text-overflow were clip. IMO, that makes the most sense, since I say that the conjunction itself does not make sense.
(In reply to Aharon (Vladimir) Lanin from comment #3)
> The logical tail end of the
> opposite-direction text that it does show is usually incomprehensible
> without its beginning, so you might as well not show the opposite-direction
> part at all.

A lot of people have requested the feature of ellipsizing away the *middle* of the text, leaving the beginning and end of the text visible, which suggests that in some situations seeing the end of the text is useful.

> I simply do not understand the utility of combining text-overflow:ellipsis
> with overflow:scroll (or auto), even without bidi. 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 you want to have
> both a scrollbar and an ellipsis?

I see your point. However, the current passion for "disappearing scrollbars" (on Mac and most touch devices) suggests that an ellipsis to indicate scrollable overflow is actually getting more useful.

> BTW, Mozilla's (or probably the current CSS spec's) treatment of the
> conjunction text-overflow:ellipsis with overflow:scroll is internally
> inconsistent. If for some strange reason one does want an ellipsis to
> indicate that stuff got clipped despite the presence of the scrollbar, then
> why just have it at one end? If you've scrolled the text into its middle
> position, you should really be showing an ellipsis at both ends.

http://dev.w3.org/csswg/css-ui/#text-overflow:
"If there is one value, it applies only to the end line edge. If there are two values, the first value applies to the left edge, and the second value applies to the right edge."
This is implemented in Gecko.

> Note that (as far as I can tell from searching the Mozilla Bugzilla) no one
> is complaining about this lack of consistency. Similarly, no one has filed a
> bug on WebKit's or Chrome's admittedly silly treatment of this conjunction.
> The lack of all these bug reports indicates to me that this conjunction
> simply isn't useful.

And likewise, I'm not aware of any other bugs filed on the fact that we do visual clipping in mixed-direction text. I suspect some combination of text-overflow not being much used, and that it's historically been very poorly and non-interoperably implemented in browsers.
Also, keep in mind that "overflow:hidden" elements can be scrolled in some situations (in Firefox at least):
1) if they're contenteditable
2) by script manipulating scrollLeft/scrollTop
The latter feature is often used by pages that implement their own scrolling UI mechanisms (e.g. custom scrollbars).
> A lot of people have requested the feature of ellipsizing away the *middle* of the 
> text, leaving the beginning and end of the text visible, which suggests that in
> some situations seeing the end of the text is useful.

Ellipsizing away the middle sounds very useful, perhaps even more useful than ellipsizing away the end. That does not make ellipsizing away the start any more useful.

BTW, ellipsizing away the middle would still have bidi logical vs visual issues, probably even more severe ones than just ellipsizing away the end. For example, a visual approach for a case that starts with an opposite-direction phrase may ellipsize away the logical start of the opposite-direction phrase while displaying its logical end - i.e. the logical middle of the whole text.

BTW 2: How would ellipsizing away the middle work in combination with a scrollbar??

> I see your point. However, the current passion for "disappearing scrollbars" (on
> Mac and most touch devices) suggests that an ellipsis to indicate scrollable
> overflow is actually getting more useful.

Except that an ellipsis without overflow:scroll is not scrollable, and a user can't tell the difference between this ellipsis and that ellipsis without actually trying to scroll. Nor does ellipsis help to indicate the availability of vertical scrolling. So, if an indicator is needed, someone should come up with one (either on the browser or on the app level); an ellipsis does not sound like a good candidate.

> If there are two values, the first value applies to the left edge, and the
> second value applies to the right edge.

Ooh, good point! But look at it this way: if I saw the need for that feature without realizing it already exists, perhaps I am not 100% crazy when I see the need for logical clipping. :-)

> Also, keep in mind that "overflow:hidden" elements can be scrolled in some
> situations (in Firefox at least)

My point is that text-overflow:ellipsis makes little sense on a horizontally scroll-able element, however that scroll-ability is achieved. Thus, text-overflow:ellipsis could also be ignored on an overflow:hidden element that has a non-zero scollLeft.
(In reply to Aharon (Vladimir) Lanin from comment #6)
> > A lot of people have requested the feature of ellipsizing away the *middle* of the 
> > text, leaving the beginning and end of the text visible, which suggests that in
> > some situations seeing the end of the text is useful.
> 
> Ellipsizing away the middle sounds very useful, perhaps even more useful
> than ellipsizing away the end. That does not make ellipsizing away the start
> any more useful.

We never ellipsize away the logical start of a line of text.

> BTW, ellipsizing away the middle would still have bidi logical vs visual
> issues, probably even more severe ones than just ellipsizing away the end.

Yes. Ellipsizing away the middle is even harder to specify and implement than anything we're discussing here, which is why we (i.e. everyone) has rejected this feature request.

> > I see your point. However, the current passion for "disappearing scrollbars" (on
> > Mac and most touch devices) suggests that an ellipsis to indicate scrollable
> > overflow is actually getting more useful.
> 
> Except that an ellipsis without overflow:scroll is not scrollable, and a
> user can't tell the difference between this ellipsis and that ellipsis
> without actually trying to scroll. Nor does ellipsis help to indicate the
> availability of vertical scrolling.

It seems that the reason people want ellipses for horizontal text is because it can be hard to tell whether text has been clipped at the end or not; the visual difference is often negligible. On the other hand, people seem to be able to intuit whether vertical scrolling is possible (maybe they just assume it's always possible and use cheap scrolling gestures to check) and don't request visual indications of vertical scrollability. I'm basing this on requests from people building FirefoxOS apps.

> Ooh, good point! But look at it this way: if I saw the need for that feature
> without realizing it already exists, perhaps I am not 100% crazy when I see
> the need for logical clipping. :-)

You're not 100% crazy or we wouldn't be having this conversation :-).

> My point is that text-overflow:ellipsis makes little sense on a horizontally
> scroll-able element, however that scroll-ability is achieved.

I don't agree. How about we take this discussion to the www-style list? It really belongs there.
> We never ellipsize away the logical start of a line of text.

Sure you do. Try this:
data:text/html,<div dir=rtl style="white-space:pre; overflow:hidden; text-overflow:ellipsis; width:100px;">Hello, beautiful bidi world</div>

> How about we take this discussion to the www-style list? It really belongs there.

I agree. How should we do this - just put a link here for all the details, or try to summarize the back-and-forth above up front?
(In reply to Aharon (Vladimir) Lanin from comment #8)
> Sure you do. Try this:
> data:text/html,<div dir=rtl style="white-space:pre; overflow:hidden;
> text-overflow:ellipsis; width:100px;">Hello, beautiful bidi world</div>

OK.

> > How about we take this discussion to the www-style list? It really belongs there.
> 
> I agree. How should we do this - just put a link here for all the details,
> or try to summarize the back-and-forth above up front?

Both. You can summarize if you like.
One more thing before I do that, in the hope that we could come closer to consensus:

Another solution to the scrolling dilemma would be to specify that text-overflow with values other than clip works visually in the presence of scrolling (overflow:scroll, overflow:auto, or non-zero scrollLeft). After all, scrolling is inherently visual, and the original bidi problem does not exist when the element is scrollable, since the user can see the missing content by actually scrolling. Otherwise, text-overflow with values other than clip would work logically.
Yes, that sounds reasonable. However, I would make text-overflow visual for overflow-x:scroll/auto and not make it dependent on scrollLeft --- that way, changing scrollLeft doesn't affect layout.
> However, I would make text-overflow visual for overflow-x:scroll/auto
> and not make it dependent on scrollLeft

Earlier, you said:

> Also, keep in mind that "overflow:hidden" elements can be scrolled in some
> situations (in Firefox at least):
> 1) if they're contenteditable
> 2) by script manipulating scrollLeft/scrollTop
> The latter feature is often used by pages that implement their own scrolling UI
> mechanisms (e.g. custom scrollbars).

That was the reason I had mentioned non-zero scrollLeft. Do you see any other way of flipping to visual text-overflow in the presence of custom scrollbars?
Special-casing scrollLeft==0 is no good for custom scrollbars anyway. You don't want the rendering to change entirely just because you scrolled by 1px.
Summary of the above posted on www-style, http://lists.w3.org/Archives/Public/www-style/2013Jun/0500.html. Discussion should continue there.
See Also: → 1094131
See Also: → 1138350
Test case has been added in moztrap:
https://moztrap.mozilla.org/manage/case/15930/
Flags: in-moztrap+
See Also: → 1151925
Nominate to 2.2+ as this one blocks multiple RTL 2.2+ blockers.
blocking-b2g: --- → 2.2+
To be clear, we can workaround this issue quite easily as we did already. This involves adding an extra container. This is quite painful to do it everywhere so it would be better to resolve this bug instead, but if it gets too risky or complex just please know we can do otherwise.
Summary: text-overflow:ellipsis and text-overflow:<string> work incorrectly for bidi text → [RTL] text-overflow:ellipsis and text-overflow:<string> work incorrectly for bidi text
(In reply to Julien Wajsberg [:julienw] from comment #18)
> To be clear, we can workaround this issue quite easily as we did already.
> This involves adding an extra container. This is quite painful to do it
> everywhere so it would be better to resolve this bug instead, but if it gets
> too risky or complex just please know we can do otherwise.

HI Julien,
I see bug 1152222, bug 1152228, and bug 1152230 are all resolved. Do we still want to fix this bug?
Thanks!
Flags: needinfo?(felash)
Yes, there is a real bug in Gecko IMO. But maybe not as a blocker, as I explained in comment 18.
Flags: needinfo?(felash)
(In reply to Julien Wajsberg [:julienw] from comment #20)
> Yes, there is a real bug in Gecko IMO. But maybe not as a blocker, as I
> explained in comment 18.

given this, I don't think we need to block 2.2, co clearing the nom here, but lets track it to get fixed.

Julien, who on the gecko team can help with this ?
blocking-b2g: 2.2+ → ---
Given the bug's history, I'd say :roc would know :)
Assignee: nobody → tclancy
Status: NEW → ASSIGNED
I'm firmly of the opinion that we should use logical clipping, not visual clipping, as described at http://lists.w3.org/Archives/Public/www-style/2013Jun/0614.html (part of the discussion linked by Comment 14).

Doing so would fix issues like 1152082, where the ellipsis is being put on the wrong side.

The post linked above discusses appending an LRM or RLM to the truncated string (according to the directionality of the first replaced character) so the ellipsis will be positioned where the text is omitted. I also think it would be a good idea to append a ZWJ character (before the LRM/RLM) so that when Arabic text is truncated in the middle of a word, the last displayed letter isn't given a "final glyph" shape which it otherwise wouldn't have.

I also think it's worth noting that truncation should only happen before a letter (bidi category L), not before a mark (bidi category M). For Latin text, this is equivalent to making sure accents (diacritics) aren't separated from their base letter. It's more important for a language like Hindi, where the vowel marks can have horizontal width, and sometimes appear to the left of the base consonant. If truncation were to occur between such a vowel mark and its base consonant, the text leading up to an ellipsis would look wrong.
See Also: → 1165173
Iteration: --- → 42.1 - Jul 13
This is a work-in-progress patch. It truncates bidi text logically (rather than physically).

It builds, in case you want to play with it, but note the following problems:
* Right now, it just truncates the text without showing ellipses
* Scrollable text just vanishes.
* It uses logical truncation everywhere, instead of where it makes sense.

I have TODO comments in all the places where more work needs to be done.

I have to go work on some other things right now, but hopefully I can come back to this soon, or maybe someone can take it over.
Fixing this bug would be a spec violation. See roc's comments above on why it is the way it is. If you want to change this, you'll also need to convince the CSSWG to make the change.
(In reply to fantasai from comment #27)
> Fixing this bug would be a spec violation. See roc's comments above on why
> it is the way it is. If you want to change this, you'll also need to
> convince the CSSWG to make the change.

But how do we convince the CSSWG to listen? Aharon answered roc's comments and made the case for changing the spec over two years ago in http://lists.w3.org/Archives/Public/www-style/2013Jun/thread.html#msg500, with support from another Bidi expert, Mati Allouche, and there wasn't much response from the WG beyond "we already made up our minds about this".
There doesn't seem to be a very conclusive conclusion from the thread there. Aharon makes the case for switching to logical truncation, Mati and roc both have arguments for not doing so. There was no official response from either the CSSWG or the i18nWG. I can put it on the CSSWG agenda, but it would help to have good examples and a clearer idea of whether there is even a consensus on which is the better choice from the i18n/bidi/rtl communities.
> Aharon makes the case for switching to logical truncation,
> Mati and roc both have arguments for not doing so.

It is not true that Mati is against logical truncation. He is *for* it, as you can see in http://lists.w3.org/Archives/Public/www-style/2013Jun/0605.html. He is bikeshedding the preferred location of the ellipsis in logical truncation.

The bug assignee didn't login in Bugzilla in the last 7 months, so the assignee is being reset.

Assignee: ted.clancy → nobody
Status: ASSIGNED → NEW
Severity: normal → S3

The severity field for this bug is relatively low, S3. However, the bug has 3 duplicates.
:emilio, could you consider increasing the bug severity?

For more information, please visit auto_nag documentation.

Flags: needinfo?(emilio)
Flags: needinfo?(emilio)
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: