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

Quick follow-up on this, as further research has shown inconsistent
treatment of when the first inline atomic (element or character)
doesn't fit, which differs from treatment of latter inline atomics on
a line with text-overflow: ellipsis.

Here is a test case you can check for yourselves:

And here are the results I got in Opera, Chrome, Safari, Firefox
(respectively) on Mac.

And here is a screenshot of IE10:

I think IE10's treatment is the most reasonable and consistent, and
I'm wondering if other implementations are willing to change their
treatment of those test cases to match. That's the direction that
we're leaning with Firefox/Gecko.



On Mon, Dec 12, 2011 at 13:18, Tantek Çelik <> wrote:
> 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].
> Thanks,
> Tantek
> [1]
> [2]
> [3]
> [4]
> [5]
> [6]
> On Wed, Nov 23, 2011 at 06:17, Boris Zbarsky <> 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
> --
> - I made an HTML5 tutorial!

-- - I made an HTML5 tutorial!

Received on Sunday, 1 January 2012 00:01:15 UTC