Html: Should innerText have a blocklist of elements it doesn't work on?

[domenic]

See previous discussion in https://github.com/w3c/web-platform-tests/pull/4403#issuecomment-269554687 with @sleevi. I wrote some tests, which are in https://github.com/w3c/web-platform-tests/pull/4403 (live at http://w3c-test.org/submissions/4403/innerText/setter.html) which show that:

• Edge and Firefox behave as per spec; they do not prohibit innerText on any elements
• Chrome prohibits innerText on a set of elements consisting of: the void elements plus basefont, menuitem*, and image.
• Safari TP prohibits innerText on a set of elements consisting of: the void elements minus track and keygen, plus basefont and image.

My instinct is that we should stick with the current spec and file bugs on Blink and WebKit, but I'd love to hear from implementers in Blink and WebKit what they think. @foolip @tkent-google @cdumez ?

(* = menuitem only is blocked in Chrome when the flagged menuitem implementation is turned on.)

Note that the spec for innerText is relatively new (https://github.com/whatwg/html/pull/1678, 2016-08-17) so it's not as if this was a deliberate "spec violation" from Blink/WebKit: it's more just that when performing the reverse-engineering process for speccing innerText, we didn't think to test elements besides <div>.

[domenic]

It's also worth noting that textContent works on all these elements, which argues to me that there's no principled reason to prevent innerText from working on them.

[sleevi]

For context: The set of elements is https://github.com/w3c/web-platform-tests/pull/4403#issuecomment-269556287

[cdumez]

WebKit was doing this to match IE. Since Edge no longer behaves this way and since no longer throwing should be fairly safe compatibility wise, I think it would be OK to align WebKit with the specification. Of course , this is provided that Blink devs agree to do the same.

[zcorpan]

we didn't think to test elements besides <div>.

No, we knew about the blocklist, but Gecko decided to not copy it since it seemed unlikely to be necessary for Web compat. See https://github.com/whatwg/html/issues/1679

Chromium throws for <br>.innerText = "x" etc, Gecko does not.

Also tested at https://github.com/w3c/web-platform-tests/pull/3491

IE had a similar blocklist for innerHTML and appendChild, if I remember correctly, but that was later removed.

[tabatkins]

Yeah, I don't see a good reason to have the blocklist. We can just remove it. I've filed a bug on Chrome https://bugs.chromium.org/p/chromium/issues/detail?id=679069

[domenic]

Yeah, agreed. Just hoping to get an official Blink implementer OK, then we're good to go and can merge the various web platform test PRs. Maybe the crbug triage process will get us there sooner than pinging people on GitHub :)

[dominiccooney]

I think this is fine. I'll change Blink after the upstream test changes land.

[domenic]

Great. It sounds like this is settled. What remains is to merge https://github.com/w3c/web-platform-tests/pull/3491 and https://github.com/w3c/web-platform-tests/pull/4403 and then file bugs on browsers. \o/

[domenic]

Filed/commented:

• https://bugs.webkit.org/show_bug.cgi?id=160971#c9
• https://bugs.chromium.org/p/chromium/issues/detail?id=679069#c4
• https://developer.microsoft.com/en-us/microsoft-edge/platform/issues/10489859/

Thanks all! And @zcorpan, sorry for not realizing this was already on your radar. Hopefully we can all go through the rest of your web platform test PRs soon.

[tabatkins]

And we just fixed the bug (assuming it doesn't end up reverted) https://bugs.chromium.org/p/chromium/issues/detail?id=679069#c8