Re: RFC from implementers on Element.innerText

On Fri, Jul 29, 2011 at 6:54 PM, Edward O'Connor <eoconnor@apple.com> wrote:
>> 1) Browsers drop innerText support entirely, like Gecko now.
>
> We're not interested in dropping support for innerText--there's too much
> risk of breaking compat with the Web.
>
>> 2) Spec innerText to be like textContent but with whatever the bare
>> minimum of differences are to be web-compatible, like Opera now.
>> Authors who want to convert nodes to plaintext will have to use
>> Selection.toString(), which will either remain unspecified or be
>> specified separately.
>>
>> 3) Spec innerText to be some sort of complicated pretty-printing
>> mechanism, as compatible as possible with how browsers currently work.
>>  The same algorithm could then optionally be reused for
>> Selection.toString().
>
> Between these two we much prefer option 3. Option 2 is likely not
> backwards compatible enough for us or for the Web. Going this route
> would also not help us produce a cross-browser, rendering-aware text
> iteration algorithm that would be useful elsewhere on the Web platform
> (for Selection.toString(), as you mentioned, and potentially elsewhere).
> We're very interested in minimizing the (considerable) cross-browser
> pain for authors in this area, and are enthusiastic about converging
> innerText behavior between browser engines.

Why do you think (2) is likely not backwards compatible enough for the
web?  The innerText uses I found when I researched this would
basically work with (2), and Opera apparently hasn't run into
crippling incompatibilities.  I understand it's not going to be
compatible with WebKit-specific content, but web content has never
been able to rely on any particular innerText behavior anyway.  Gecko
doesn't do it at all, IE/WebKit/Opera all do it quite differently, and
IIRC there are large differences even between IE versions.

Anyway, Microsoft and WebKit will not do (1), so it's out.  WebKit
doesn't like (2) but it's not clear whether they absolutely won't do
it; everyone else is fine with it.  Gecko will probably not do (3),
but everyone else is fine with it.  These days, WebKit and Gecko have
comparable market share, so it's a toss-up on that basis.

The problem with (3) is that it would be very hard to spec; it would
be even harder to spec in a way that all browsers can implement; and
any spec would probably have to be quite incompatible anyway with the
existing implementations that follow the general approach.  So my
conclusion is that we go with (2) for now, since it's almost trivial
to spec.  If browsers wind up converging on it, good.  If not -- e.g.,
Microsoft or WebKit try it and find unacceptable compatibility issues
-- we can consider rewriting it later to be more complicated, perhaps
together with Selection.toString().

I'll update the bug shortly and we can wait for Ian's take.

Received on Tuesday, 2 August 2011 15:23:13 UTC