25159 2014-03-26 16:42:34 +0000 Specify HTMLElement.innerText and outerText 2014-09-17 02:36:05 +0000 1 1 1 Unclassified WHATWG Unwelcome unspecified Other other RESOLVED DUPLICATE 13145 http://www.whatwg.org/specs/web-apps/current-work/#elements-in-the-dom P3 normal Unsorted 1 contributor mike ian mike philipj zcorpan sideshowbarker+unwelcome oldest_to_newest 102927 0 contributor 2014-03-26 16:42:34 +0000 Specification: http://www.whatwg.org/specs/web-apps/current-work/ Multipage: http://www.whatwg.org/C#elements-in-the-dom Complete: http://www.whatwg.org/c#elements-in-the-dom Referrer: Comment: Specify HTMLElement.innerText and outerText Posted from: 113.23.85.162 User agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_9_2) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/33.0.1750.117 Safari/537.36 OPR/20.0.1387.59 (Edition Next) 102928 1 philipj 2014-03-26 16:44:24 +0000 I added counters to see if these could be dropped from Blink, but they're used a lot: http://www.chromestatus.com/metrics/feature/timeline/popularity/213 http://www.chromestatus.com/metrics/feature/timeline/popularity/214 In my ad-hoc testing Firefox is the only browser to not support it, so specifying it seems like the path of least resistance. HTML, DOM, or DOM Parsing and Serialization seems like the place for this, so I'm starting with where HTMLElement is defined. I guess it wouldn't hurt to put it on Element, but that's not required for Web compat, or at least it's not where Blink/WebKit puts it. 103183 2 ian 2014-03-31 17:10:59 +0000 Do you have a definition I could use to spec them? Last I checked, I couldn't figure out what they did. 103188 3 philipj 2014-03-31 18:14:11 +0000 I had a look at Blink and had no idea innerText was this crazy. The innerText getter uses the line boxes from the render tree in some way, but falls back to just textContent in the absence of a renderer. The outerText getter is just an alias for innerText. The innerText setters replaces newlines in the input with <br> elements, but also has some scary things involving the rendered. The outerText setter looks more sane, I think it just replaces newlines with <br>. I think maybe a sensible first attempt would be to reverse engineer the interoperable subset of how these properties work on elements not inserted into a document, which would be something like a "semantic textContent". If it turns out that applying CSS is needed for Web compat, this is going to be pretty ugly. I can help out with Blink use counters to determine what's Web compatible and not. 103198 4 zcorpan 2014-03-31 20:42:52 +0000 Aryeh worked on a spec for it before. It seems it's gone but I found some backup: https://rawgithub.com/jackcviers/Rangy/master/spec/innerText.htm See http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2011-February/030179.html Also Selection.toString() supposedly should do the same thing as innerText. https://www.w3.org/Bugs/Public/show_bug.cgi?id=10583 https://dvcs.w3.org/hg/editing/raw-file/tip/editing.html#dom-selection-stringifier 103393 5 zcorpan 2014-04-04 06:26:16 +0000 https://web.archive.org/web/20110205234444/http://aryeh.name/spec/innertext/test/innerText.html relic from the tests. 105344 6 ian 2014-05-07 20:43:59 +0000 I think the first step here is figuring out what these actually need to be. If it depends on CSS, which it seems likely to, then this is probably at best something for CSSOM. 111656 7 ian 2014-09-17 02:36:05 +0000 *** This bug has been marked as a duplicate of bug 13145 ***