Re: RFC from implementers on Element.innerText

On Aug 1, 2011, at 11:19 AM, Aryeh Gregor wrote:

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

Personal opinion: if the options are to make innerText different from any other text conversion, vs make it identical to Selection.toString(), then it seems like the latter option makes the spec simpler overall, even if it makes innerText itself more complicated.

Regards,
Maciej

Received on Monday, 1 August 2011 20:21:08 UTC