Re: RFC from implementers on Element.innerText

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

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:

http://html5.org/specs/dom-range.html#dom-selection-stringifier

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

Received on Tuesday, 2 August 2011 17:30:21 UTC