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

On Sun, Jan 23, 2011 at 19:04, Robert O'Callahan <robert@ocallahan.org> wrote:
> On Mon, Jan 24, 2011 at 8:02 AM, Tantek Çelik <tantek@cs.stanford.edu>
> wrote:
>>
>> On Sun, Jan 23, 2011 at 00:56, Robert O'Callahan <robert@ocallahan.org>
>> wrote:
>> > On Sat, Jan 22, 2011 at 7:53 PM, Tantek Çelik <tantek@cs.stanford.edu>
>> > wrote:
>> >>
>> >> I've applied the filter of only documenting what appears to be
>> >> interoperably implemented,
>> >
>> > Unfortunately, only the simplest situations are handled interoperably
>> > among
>> > IE, Webkit and Opera, so documenting the interoperable stuff leaves most
>> > behavior undefined :-).
>>
>>
>> If that's so, then web authors/developers are unlikely to be depending
>> on things other than "the simplest situations".
>>
>> That will do for CSS3-UI.  Anything that is currently not
>> interoperable among the three implementations I will leave explicitly
>> undefined / up to the implementation in CSS3-UI.
>
> Personally I would rather not have the feature appear in a spec, than have
> it appear with such a large volume of undefined behavior. If it was a
> genuinely new feature I would object most strenuously.

I tend to agree. Any genuinely new feature should be specified with
sufficient detail for implementations to interoperate just by reading
the spec (and perhaps using test cases).


> Since text-overflow
> is already being used in the wild without prefix, I guess having CSS3UI
> describe it is OK. But I think at least there should be strong warnings in
> the spec noting the known areas of undefined behavior, e.g.

This seems reasonable to me. Known unknowns and all that.


> "WARNING: the behavior of text-overflow:ellipsis on a block with 'overflow'
> other than 'hidden' is currently undefined.

I might just call out overflow:scroll instead, which does appear to
have some interop, but not necessarily ideal behavior. This case is
outside the common practical use case of overflow:hidden
text-overflow, and thus I'm more willing to consider a design that is
better than existing implementations since they may be more willing to
change. I will research this and write-up a proposal.


> The effect of
> text-overflow:ellipsis on lines whose line boxes are not direct children of
> the block box(es) with text-overflow is currently undefined.

I think this *is* actually both well defined (if indirectly) and
interoperable. That is, the effect of the definition in the spec is
that *only* the direct block element parent of line boxes can affect
the text-overflow behavior of those line boxes since text-overflow is
not inherited by default (and each block element potentially sets its
own dimensions and overflow).


> The interaction
> of text-overflow:ellipsis with event handling is currently undefined.

Captured. Barring some test that demonstrates interop, I will write
this up as undefined.


> The
> behavior of text-overflow:ellipsis on lines containing replaced elements is
> currently undefined.

Captured. This one I'm guessing will likely interoperate but need to
write-up some test cases to demonstrate. If not then I will write this
up as undefined.

Another related case will be when floats impose on lines that text-overflow.



> The behavior of text-overflow:ellipsis on lines
> containing right-to-left text is currently undefined.

I believe per the testing we've done with IE, Opera, Safari and the
definition in the spec, this *is* now defined and interoperable.


I really appreciated this list of potential unknowns, and I encourage
the contribution of any more that anyone thinks of.

I'd very much like to either define what must/should happen, or
explicitly note that the spec leaves it open for now (with perhaps
SHOULDs based on what we think is a good design, in the hopes that
implementations head that direction and we can specify it more
strongly in CSS4-UI).

Thanks Rob,

Tantek

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

Received on Tuesday, 1 February 2011 02:12:59 UTC