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

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

From: Tantek Çelik <tantek@cs.stanford.edu>
Date: Mon, 12 Dec 2011 13:18:30 -0800
Message-ID: <CAOACb=JfkbLeoyBA+ZnLvubPLk=4cAk_WdiHqEAD6XHHqhYGbQ@mail.gmail.com>
To: Boris Zbarsky <bzbarsky@mit.edu>
Cc: www-style list <www-style@w3.org>
Per implementation interop as noted by Boris, and web-compat
[1][2][3][4][5], I've updated text-overflow to specify that inline
atomic elements are to be clipped rather than ellipsed.


Please let me know if if you have reasons or evidence to suggest
alternative approaches.  Or if you know of other sites with web-compat
issues with ellipsing inline atomic elements, please feel free to add
to [6].



[1] https://bugzilla.mozilla.org/show_bug.cgi?id=680610
[2] https://bugzilla.mozilla.org/show_bug.cgi?id=689897
[3] https://bugzilla.mozilla.org/show_bug.cgi?id=690131
[4] https://bugzilla.mozilla.org/show_bug.cgi?id=690187
[5] https://bugzilla.mozilla.org/show_bug.cgi?id=703360
[6] https://wiki.mozilla.org/CSS/text-overflow#ellipsing_of_inline_atomic_content

On Wed, Nov 23, 2011 at 06:17, Boris Zbarsky <bzbarsky@mit.edu> wrote:
> 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

http://tantek.com/ - I made an HTML5 tutorial! http://tantek.com/html5
Received on Monday, 12 December 2011 21:19:50 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 11 February 2015 12:35:01 UTC