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

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.

http://dev.w3.org/csswg/css3-ui/#text-overflow

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] 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