Upstream the innerText spec

[zcorpan]

From https://rocallahan.github.io/innerText-spec/ with no normative
changes except adding [CEReactions] to the IDL.

Fixes #465.

---

@Ms2ger @rocallahan

[annevk]

"a ranges" -> "a range" | "ranges"

[annevk]

comma after e.g.

[annevk]

@domenic and I started using "this element" (or equivalent) in other algorithms. I think that would be a clearer way to refer to the object on which the IDL attribute is defined.

[annevk]

Make this end in parenthesis?

[zcorpan]

Hmm I suppose " and concatenating the results" should be removed here.

[zcorpan]

Hmm, no this should still be there. Each child produces a list, and we want to concatenate those lists into one...

[annevk]

This looks like a note, mark it up as such and avoid normative requirements?

[annevk]

then return*

[annevk]

then return*

[annevk]

This happens a few more times.

[annevk]

then append

[annevk]

This should presumably do some starts with matching? We only add "required line break count of ..." after all.

[zcorpan]

I don't follow.

[annevk]

The string being added is "required line break count of 2" / "required line break count of 1", not this string.

[zcorpan]

Ah, I see. Those items are not strings. They are integers, basically. I suppose it could be made less confusing...

[annevk]

line breaks

[annevk]

this element's

[annevk]

"the new value being assigned" -> "the given value"

[annevk]

This looks okay. The only thing I'd consider changing further is making the recursion less declarative. Have that be some algorithm that is invoked for each child and also put the result in a variable of some kind the rest of the algorithm uses. Will let @domenic make the call on that.

[zcorpan]

Yeah, it could use some more cleanup. Possibly also switch to iterative traversal instead of recursive? But I think the current state is OK to merge and I can fix more later.

[domenic]

I wonder if a better title might be something like Manipulating an element's "as rendered" text? It seems to me like other section titles usually don't talk about a specific IDL attribute. I don't feel strongly though.

[zcorpan]

It's a bit of a mix currently. Having "innerText" in the heading makes it easier to find. But if we also add outerText we can maybe change the heading at that point.

[domenic]

Should we add a warning about how developers usually want to use textContent instead?

[zcorpan]

I don't know, it's not clear to me that is usually true. For getting, innerText seems a lot more useful if you want the text but not the contents of scripts and don't want formatting of the HTML source to affect the given text. For setting, you would have to use <pre> but you might want spaces to collapse or don't want monospace font, or you could use <p> with white-space: pre-line (or so) but then you rely on CSS to preserve presumably important line breaks.

textContent is gives more consistent results cross-browser, though.

[domenic]

s/integer items/required line break count items?

Spelling is "reminiscent"

[domenic]

I guess this is the same concern as the factoring thing @annevk mentioned, but saying "return" inside a getter and that not being the result of the getter is pretty confusing. "Let the result of these substeps be items and abort these substeps"? Meh...

[zcorpan]

Yeah... I went with your suggestion for now but it's not great.

[domenic]

"text" should be https://dom.spec.whatwg.org/#concept-cd-data

[domenic]

<span> around 'table-row'?

[domenic]

No comma after HTML namespace, I think

[domenic]

LGTM. I think the original commit message is a bit outdated so I'll let you merge and write up a commit message. Also probably want to reference #1679

[smaug----]

I assume there will be tests for this in wpt.

[zcorpan]

@smaug---- there were tests in wpt already, and I have submitted these PRs to update them so far:
web-platform-tests/wpt#3482 (merged)
web-platform-tests/wpt#3483 (merged)
web-platform-tests/wpt#3491
web-platform-tests/wpt#3492
web-platform-tests/wpt#3493