Re: [CSS3-UI] text-overflow:ellipsis (freshly rewritten/expanded and incorporated into editor's draft)

On Wed, Jan 26, 2011 at 13:45, Robert O'Callahan <robert@ocallahan.org> wrote:
> On Wed, Jan 26, 2011 at 8:27 PM, Tantek Çelik <tantek@cs.stanford.edu>
> wrote:
>>
>> I've updated the editor's draft to provided a clearer description of
>> how direction/ltr/rtl interact with text-overflow ellipsis (as well as
>> provided some simple rendering examples), consistent with current
>> Opera and WebKit implementations.
>>
>> http://dev.w3.org/csswg/css3-ui/#text-overflow
>>
>
> I suggest not following Opera and Webkit for bidi behavior. This example:
> <div dir="rtl" style="text-overflow:ellipsis; overflow:hidden;
> width:60px;">HelloKitty</div>
> renders as "...Hello" in Webkit and Opera, which I think is clearly wrong.
> IE renders it as "...loKitty", which I think is right.

fantasai and I were unable to reproduce your results, on the contrary
we got interop between Opera, WebKit, IE8, IE9 on that example:

<div dir="rtl" style="text-overflow:ellipsis; overflow:hidden;
width:60px;">HelloKitty</div>

"...Hello"

that is - ALL implementations:
* truncate grapheme clusters as necessary in *reverse document source
order* regardless of block direction (dir, direction property, etc.).
* render the ellipsis on the tail of the block direction (ltr = on the
right, rtl = on the left) for text that is all in a LTR language.

If anyone see results *other* than what I've noted above, please email
your valid HTML test case as an enclosure in your reply so that we can
test the exact same code to see what is going on.


Thus unless there is contradictory data, or there is compelling
reasoning sufficient to get all three existing implementations to
change, I suggest that it is too late to bother spending any time
specifying anything other their current interop behavior on those
points.


> Also try playing with this example:
> <div style="text-overflow:ellipsis; overflow:auto; width:10%; height:100px;
> border:1px solid black; font-size:16px;
> white-space:pre;">HelloKittyוסוכנויות</div>
> IE clips visually, Webkit and Opera clip logically. I think the WG
> eventually decided that visual clipping was better (and I agree).

In this case as well there was interop across IE9/Opera/WebKit on
truncation, that is:
* all implementations truncated in reverse document source order

Rendering was slightly different.

Opera and Webkit continue with the literal visual/physical display of
ellipsis per block direction as noted above.

e.g.:

"HelloKittyוסוכנ..."

However, IE9 displayed the ellipsis *between* the HelloKitty and the
Hebrew characters (Per fantasai and my test yesterday, fantasai please
confirm this.)

"HelloKitty...וסוכנ"

Which do people think is better? Intuitively I want to say that IE9's
behavior is better since the ellipsis is rendered where the otherwise
missing characters would be.

CSS3-UI will allow for either, but we can pick whichever one is better
and make it a SHOULD in the spec.


> The problem here is that there is no real interop for text-overflow with
> bidi text.

I don't know what you mean by "real interop".

I agree that in the mixed bidi test case you provided there doesn't
seem to be complete interop, and we'll have to document it as such.

> So you have to either spec something that isn't interoperably
> implemented, or spec something that leaves bidi behavior undefined.

Absent data I reject this generalization.

I suggest we iteratively assess problems with interop on test case by
test case basis.

I am very open to seeing additional test cases that demonstrate
interop problems, with suggested resolutions as well.

Thanks,

Tantek

-- 
http://tantek.com/ - I made an HTML5 tutorial! http://tantek.com/html5

Received on Friday, 28 January 2011 04:15:07 UTC