W3C home > Mailing lists > Public > public-html@w3.org > July 2011

Re: RFC from implementers on Element.innerText

From: Boris Zbarsky <bzbarsky@MIT.EDU>
Date: Thu, 07 Jul 2011 15:16:52 -0400
Message-ID: <4E160624.1080802@mit.edu>
To: Aryeh Gregor <Simetrical+w3c@gmail.com>
CC: Adrian Bateman <adrianba@microsoft.com>, Maciej Stachowiak <mjs@apple.com>, Anne van Kesteren <annevk@opera.com>, public-html@w3.org
On 7/7/11 2:37 PM, Aryeh Gregor wrote:
> 1) Browsers drop innerText support entirely, like Gecko now.
>
> 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.

Either one of these would be fine by us (Mozilla).  I think I can claim 
this part is official.

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

I personaly am opposed to doing this, and Jonas agrees with me.  Let's 
call that semi-official.

If this were done, it would, imo:

1)  Need to actually be defined in a way that's interoperably 
implementable without imposing new constraints on the browser's CSS 
implementation (e.g. can't assume things about the structure of the box 
model that are not defined in the CSS spec).

2)  Require a commitment from the existing pretty-printing 
implementations to converge on this behavior (there's no point otherwise).

3)  Likely be a specification, if not implementation, rathole.

If, in the meantime, you want someone to poke holes in your spec from 
February, I can probably to that.  ;)  Send me a link.

-Boris
Received on Thursday, 7 July 2011 19:17:21 UTC

This archive was generated by hypermail 2.3.1 : Monday, 29 September 2014 09:39:26 UTC