Re: HTML Editing APIs specification ready for implementer feedback

Aryeh wrote:

> So at this point I'd like feedback from all the major browser
> implementers on what they want to do here. I see three basic options:
>
> 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.


Thanks,
Ted

Received on Friday, 29 July 2011 22:55:16 UTC