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

Re: RFC from implementers on Element.innerText

From: Aryeh Gregor <ayg@aryeh.name>
Date: Tue, 2 Aug 2011 13:29:24 -0400
Message-ID: <CAKA+Ax=5nMriSA6_-XM=p7EVOgqawvhb7MKoDBBsQVWqPOk=zg@mail.gmail.com>
To: Anne van Kesteren <annevk@opera.com>
Cc: Maciej Stachowiak <mjs@apple.com>, Boris Zbarsky <bzbarsky@mit.edu>, public-html@w3.org
On Tue, Aug 2, 2011 at 1:02 PM, Anne van Kesteren <annevk@opera.com> wrote:
> Why the rush? If Selection.toString() can wait, so can innerText, no?

innerText is far more widely used, so it's more important to get
interop.  It also doesn't work reliably for pretty-printing, since
Opera doesn't do pretty-printing with it and Gecko doesn't support it
at all, so it's much more practical to get it working with a minimal
spec.  In fact, a very large fraction of users only get it and don't
set it, so implementing it as an alias to textContent would be better
than nothing (unless it causes you to go down IE codepaths, of

But you're right that there's an option (4) here: leave it unspecified
indefinitely, until we have the bandwidth to write a spec for
Selection.toString(), and then match that spec.  I think that option
is worse than having a minimal spec for now, but it's on the table.
FWIW, Selection.toString() is currently defined by reference to
Range.toString(), which behaves basically like textContent:


The spec just has an XXX saying that it's known to be wrong.

Perhaps we should spec innerText in the simple way I suggest, but
leave a warning in the spec explaining the compat situation and saying
we might want to change it once we get a good definition for
Received on Tuesday, 2 August 2011 17:30:21 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 29 October 2015 10:16:16 UTC