RFC from implementers on Element.innerText

Bug: http://www.w3.org/Bugs/Public/show_bug.cgi?id=13145
WHATWG discussion in February:
http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2011-February/thread.html#30179
Preliminary spec, currently abandoned:
http://aryeh.name/spec/innertext/innertext.html

Element.innerText has been supported by IE for a long time, and has
been copied by all major browsers other than Firefox.  Maciej has
informed me that it's necessary for web-compat for non-Firefox
browsers, because sites will do things like isFirefox() ?
el.textContent : el.innerText.  I also found a site that breaks in
Firefox because it assumes innerText always works, and probably more
sites break in non-Firefox Gecko (depending on how they
browser-sniff).  So it seems clear we want a specification here.

Both IE and WebKit do some kind of pretty-printing on innerText,
adding newlines in between block elements and things like that.  In
WebKit this is the same as how Selection.toString() works, in IE it's
different.  Opera makes innerText behave like textContent with slight
differences (like converting <br> to \n), but Anne said (in the linked
bug) that this has caused compat problems.  However, Boris Zbarsky (in
the linked WHATWG discussion) expressed strongly-worded reservations
about having complicated CSS dependencies in a DOM property,
particularly given the lack of bug reports filed against Firefox on
the subject.

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.

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

In the case of (1) or (2), we don't need significant further
specification work.  In the case of (3), I'll fix up my work from
February and we can get it included in some appropriate spec, such as
HTML5 if people are okay with adding a moderately complicated feature
that might not initially be web-compatible.

Can I get official or semi-official positions from the four major
browser engines on which of the three options are
preferred/acceptable/unacceptable to them?  I don't know if there's
anything we can do that everyone will agree on, but we should get as
much agreement as possible.

Received on Thursday, 7 July 2011 18:38:26 UTC