W3C home > Mailing lists > Public > www-style@w3.org > December 2009

Re: [CSSWG] Minutes and Resolutions TPAC F2F 2009-11-02: ?text-overflow

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Fri, 11 Dec 2009 10:29:45 -0600
Message-ID: <dd0fbad0912110829x7d587e20id5008d104b0f2b0@mail.gmail.com>
To: Dan Bernstein <mitz@apple.com>
Cc: fantasai <fantasai.lists@inkedblade.net>, www-style <www-style@w3.org>
On Fri, Dec 11, 2009 at 1:26 AM, Dan Bernstein <mitz@apple.com> wrote:
> On Nov 12, 2009, at 3:29 PM, Tab Atkins Jr. wrote:
>> I thought we *did* end up resolving some of the ellipsis questions
>> over lunch-time discussions?  Specifically, I think I ended up
>> convincing people pretty well that presentation-based ellipsizing was
>> optimal (and in the general case, the only sane thing), and further
>> conversation with some people who were familiar with bidi conventions
>> in paper text supported that.
> Such “visual” truncation is truly illogical. Removing an arbitrary chunk from the middle of the text makes it hard to follow and can easily lead to misunderstanding. At the very least, it requires re-reading some of the text when it’s revealed in its entirety.

I agree that it's slightly suboptimal, but believe that logical
truncation is even worse.

> “Logical” truncation, that is, always removing the end of the text, is not only the behavior of WebKit on all platforms and of Microsoft IE, it is also the behavior of the Cocoa text system on Mac OS X and of the Windows DrawText API. As a longtime reader of bidirectional text, I don’t recall ever seeing “visual” truncation being used in print. And like I said, it is definitely not the convention in the major desktop operating systems.

Indeed, the current implementations agree.  They also agree that their
behavior is sort of insane,.  For example, they still put the ellipsis
at the right end of the box, even though the rtl text is truncated in
the 'middle'.  If they corrected the ellipsis, then you get 'jumping
ellipses' when you dynamically resize a box containing both rtl and
ltr text.

It gets worse when you fix scrolling of text-overflow boxes.  Right
now implementations all make the box as wide as it would be without
truncation, then they truncate the text and add the ellipsis, so that
if you scroll there's no text revealed, just a bunch of empty space.
Once this is fixed, how would logical truncation work with scrolling?
I could imagine how it would act, but it would be a very confusing and
strange action (you'd have rtl letters appearing in the middle of the
text, and then once it was only rtl on the screen it would scroll in
the wrong direction).  Visual truncation makes things act consistently
and sanely.

(All spoken examples above assumed a box filled with 3 spans of text,
one ltr, one rtl, and the last ltr, each long enough to fill about 2/3
of a line, with the dominant text-direction being ltr.)

Received on Friday, 11 December 2009 16:30:17 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:07:41 UTC