W3C home > Mailing lists > Public > www-style@w3.org > November 2011

[css3-ui] text-overflow:ellipsis interaction with atomic inline elements is not web-compatible

From: Boris Zbarsky <bzbarsky@MIT.EDU>
Date: Wed, 23 Nov 2011 09:17:25 -0500
Message-ID: <4ECD0075.9000109@mit.edu>
To: www-style list <www-style@w3.org>
The current draft for text-overflow:ellipsis specifies that atomic 
inlines are to be elided entirely if they overflow.  This is not 
compatible with the Presto, Trident, or WebKit implementations of 
text-overflow.  I can see how one might think it's the only "sane" 
behavior, but I don't see how one might think that specifying something 
that's inconsistent with all existing UAs in that it makes content 
that's visible in all of them disappear would be web-compatible.

And in fact, since we shipped an implementation of this draft in Gecko a 
few months ago we've had numerous reports of problems caused by this 
part of the spec, including in somewhat widely deployed webmail and 
forum systems which can't be easily modified by their users.

What I propose (and what I will push for in Gecko independently of what 
actually happens with the spec) is that atomic inline behavior match 
that of shipping implementations.  If the "sane" behavior is desired, it 
should just be attached to a new value of text-overflow, imo.

As a general note, I'm really not sure how this was expected to work. 
Seems to me that changes from widely deployed behavior are only 
possible, if possible at all, with widespread UA buy-in, including UAs 
committing to shipping the change more or less contemporaneously.  I see 
no evidence that such buy-in exists or was sought in this instance, so 
the only real effect of the current draft spec is to punish UAs who 
think to actually base their implementation on the spec by causing them 
to not be interoperable with existing content.  This seems like about 
the worst failure mode a specification this group produces can have, 
from my UA author perspective.

Regards,
Boris
Received on Wednesday, 23 November 2011 14:18:10 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 17:20:46 GMT