- From: Aharon (Vladimir) Lanin <aharon@google.com>
- Date: Wed, 26 Jun 2013 17:24:36 +0300
- To: Matitiahu Allouche <matitiahu.allouche@gmail.com>
- Cc: 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+FsOYbOM9DagH1pm92phJrjLvvMFYucmkFxnwVDCboL5inLow@mail.gmail.com>
On Mon, Jun 24, 2013 at 7:08 PM, Tab Atkins Jr. <jackalmage@gmail.com> wrote: > We had this exact discussion some time ago, and decided very > deliberately that we wanted the ellipsis to be a visual effect, not a > logical one. I'd recommend searching the mailing lists for these > discussions first, so you can see the older arguments for it. > Here are the arguments for visual truncation that I've been able to find, primarily in the Minutes and Resolutions from the F2F at TPAC 2009-11-02<http://lists.w3.org/Archives/Public/www-style/2009Nov/0219.html>. As far as i can see, there has been very little actual discussion of the pros and cons on www-style itself. There was some discussion in 2011, but it seemed to concentrate on what exactly is the behavior of different browsers, not on the pros and cons of different options. - Visual truncation is easier to implement. Perhaps. But it does not mean that visual truncation gives good-enough results for bidi text, and implementing the wrong thing cheaply does not sound like the right decision. Nor does it mean that implementing logical truncation (I mean without major bugs) in a scroll-less element has to be prohibitively expensive. Conceptually and computationally, logical truncation should be very similar to wrapping, and should be no more difficult to implement. When the line can't hold any more content, instead of wrapping, one truncates. The major difference is that the calculation of whether we have run out of room needs to take the width of the ellipsis in mind. And, of course, as currently spec'ed, the truncation for ellipsis can happen in the middle of a word - although it would actually be a lot more useful to truncate on a word boundary, exactly as in wrapping. - Logical truncation does not seem to be compatible with scrolling. I agree. Nor is logical truncation needed when the user can scroll the content, and so I am proposing doing it only for elements with overflow-x:hidden. Other elements should indeed get visual truncation. - Visual truncation is "easier to understand". I am not sure what specifically was judged to be more difficult to understand about logical truncation. If it is the location of the ellipsis (see below), it can be addressed. IMO, visual truncation is not so easy to understand either. Yes, a savvy user should realize that what they are seeing is a visual truncation, similar to the visual clipping with which they are familiar from scrolling etc. But I don't think that a not-so-savvy user will get that. And even for the savvy user, being able to understand what has happened is very difficult from liking it. Yes, when I see that my laptop is suddenly shutting down of its own volition, i *understand* that it has probably run out of power. That does not mean that I *like* it. And I do not think that being able to see a random, non-contiguous bit of opposite-direction text before the ellipsis, with no way to get the part that came before it is very useful, so I have no reason to like it. - Placing the ellipsis at the visual overflow boundary while truncating the text logically puts the ellipsis far away from the truncated text (in the bidi case). I do agree that this placement of the ellipsis is somewhat confusing, and I would prefer it to be placed at the truncation point. But others (e.g. Mati) seem to prefer the other location. Either way, the maximum damage that the wrong choice for the ellipsis location will do is confuse the user. As I said above, I consider that to be of secondary importance to giving a more useful result. - WebKit and Blink do weird stuff when truncating text containing inline boxes. This is just a bug. I don't think that it even confirms that logical truncation is seriously difficult to implement. IE does *not *have this problem. On Wed, Jun 26, 2013 at 9:38 AM, Matitiahu Allouche < matitiahu.allouche@gmail.com> wrote: > 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? > I think that the way to do the ellipsis is as follows: - Find the first character to be truncated, i.e. the first one logically that will not appear. This should never be be an explicit directional formatting character (LRE, RLE. PDF, etc.), since they are zero-width. - Replace that character with the ellipsis (putting it in a directional isolate if it is a custom string, as opposed to the bidi-neutral ellipsis character itself). - Append an LRM if the bidi level of the replaced character was even, and an RLM otherwise. This will make sure to put the ellipsis exactly where the first truncated character would have gone. BTW, in this approach, it only makes sense to give the ellipsis the same style as the first truncated character. 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. > True. However, in most cases, the user only really cares to know whether some text is missing if the user has bothered to read the text that's there to the end. And if that is the case, the user will end up at the ellipsis anyway.
Received on Wednesday, 26 June 2013 14:25:28 UTC