- From: Aryeh Gregor <Simetrical+w3c@gmail.com>
- Date: Thu, 7 Jul 2011 14:37:38 -0400
- To: Adrian Bateman <adrianba@microsoft.com>, Boris Zbarsky <bzbarsky@mit.edu>, Maciej Stachowiak <mjs@apple.com>, Anne van Kesteren <annevk@opera.com>
- Cc: public-html@w3.org
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