spec innerText

[karlcow]

The innerText is used in a number of Web sites creating interop issues.

see https://bugzilla.mozilla.org/show_bug.cgi?id=264412

[Ms2ger]

When Aryeh wrote a spec, nobody was interested in implementing it; what makes you think this attempt will go any better?

[karlcow]

@Ms2ger Yeah one of these. It might not get any better. I usually don't think ;) I'm opening the issues on what is needing for the Web Compatibility. We will figure out if/how to spec it if/when implemented.

Currently it is mostly used as a replacement for textContent in all the bugs we can see.

[karlcow]

Some background:
http://perfectionkills.com/the-poor-misunderstood-innerText/#naive-spec
http://kangax.github.io/jstests/innerText/
https://www.w3.org/Bugs/Public/show_bug.cgi?id=13145
https://lists.w3.org/Archives/Public/public-webapps/2014JulSep/thread.html#msg580
http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2011-February/030179.html

webcompat/web-bugs#633
webcompat/web-bugs#1051
webcompat/web-bugs#1071
https://bugzilla.mozilla.org/show_bug.cgi?id=914252#c16 (Google calendar and Gmail)

[foolip]

I wrote some things in a duped bug:
https://www.w3.org/Bugs/Public/show_bug.cgi?id=25159

Usage is very high:
http://www.chromestatus.com/metrics/feature/timeline/popularity/213
http://www.chromestatus.com/metrics/feature/timeline/popularity/214

As implemented in Blink these attributes depend on layout, but it's not obvious that this is required for web compat, maybe a "semantic textContent" that does special things for a small number of elements like <br>, <p> and <div>.

However someone attempts to specify it, I'd be happy to investigate the difference between that and what's implemented in Blink.

[foolip]

Next up on the ladder of crazy would be depending on the computed style, which is still better than depending on the layout structure itself, IMHO.

[myakura]

fyi Anne said "To do this right, you would first have to standardize selection." http://discourse.wicg.io/t/standardizing-innertext/799/2

[foolip]

@annevk, what does that mean? Not http://w3c.github.io/selection-api/ I take it?

[annevk]

Yes, that. innerText is effectively selection.toString().

[foolip]

Oh, and that's undefined in the spec with a link to https://www.w3.org/Bugs/Public/show_bug.cgi?id=10583

So in other words, what we need is a common algorithm that takes a range (containing the context object for outerText and the children for innerText) and returns a string?

I guess setting innerText and outerText has no equivalent in the Selection API?

[annevk]

Setting operates on the DOM directly, with no regards for layout? Or is setting "magic" too?

[foolip]

For some odd reason, HTMLElement::setInnerText checks the layout to see if newlines should be preserved, surrounded with FIXMEs, in what should be equivalent to checking the white-space property on the computed style. I guess it's so that innerText works as "expected" on <pre>.

The outerText setter doesn't do anything like that, though.

[annevk]

Well if you just set textContent, <pre> works "as expected". It must be something else.

[foolip]

It's weird, in the normal case the text is converted to Text nodes and <br>s, but in the preserveNewline() case newline characters are used instead. Not sure why, the visual result is the same in either case. Test case:
http://software.hixie.ch/utilities/js/live-dom-viewer/saved/3578

[stuartpb]

I've drafted a proposal for a robust, CSS-based approach to the element -> text conversion both selection.toString() and innerText would use: http://discourse.wicg.io/t/css-plain-text-conversion/976

[karlcow]

Searching innerText in Chromium

• defined as a String https://code.google.com/p/chromium/codesearch#chromium/src/third_party/WebKit/Source/core/dom/Element.h&q=innertext&sq=package:chromium&type=cs&l=398
• OuterText is defined as identical to innerText https://code.google.com/p/chromium/codesearch#chromium/src/third_party/WebKit/Source/core/dom/Element.cpp&sq=package:chromium&type=cs&rcl=1438529374&l=2565

String Element::outerText()
{
    // Getting outerText is the same as getting innerText, only
    // setting is different. You would think this should get the plain
    // text for the outer range, but this is wrong, <br> for instance
    // would return different values for inner and outer text by such
    // a rule, but it doesn't in WinIE, and we want to match that.
    return innerText();
}

• and finally the definition of innerText

String Element::innerText()
{
    // We need to update layout, since plainText uses line boxes in the layout tree.
    document().updateLayoutIgnorePendingStylesheets();

    if (!layoutObject())
        return textContent(true);

    return plainText(EphemeralRange::rangeOfContents(*this), TextIteratorForInnerText);
}