Update IDL for script enforcement

[lukewarlow]

• Node/textContent, and Element/innerText are both now shadowed on HTMLScriptElement.

HTMLScriptElement/textContent uses a union type rather than [StringContext] because it uses a nullable type.

All of the properties are using union types as that seems to be the direction the spec is going to go in. But I can revert that commit and go back to using the extended attribute.

This PR is part of 1 of addressing #437 it specifically doesn't address #483 or #252

---

Preview | Diff

[lukewarlow]

cc @mbrodesser-Igalia might be of interest to you as you start implementing more in Gecko

[lukewarlow]

@annevk hopefully this is now in a better shape. Shadows the properties onto HTMLScriptElement rather than messing with Node/textContent and Element/innerText. Uses the IDL attribute where possible so algorithms are mostly just setting the internal slot and calling the parent steps

HTMLScriptElement/textContent uses a union type instead of the IDL extended attribute to avoid issues with nullable IDL type handling.

[lukewarlow]

Updated this to link to the correct steps in the DOM and html specs so it should read better.

[lukewarlow]

@koto and @annevk does this seem ready to merge into the spec now?

[annevk]

I think I have the same question as I have for the HTML PR. Do we need to store a redundant copy of the text, or is the actual model invalidation of some kind of trusted bit.

[lukewarlow]

@annevk

Currently: We validate during prepare the text so we do need to store the text. The "invalidation" is currently only something we propose for the parsing behaviour.

It's possible that if all the ways to change the children of a script element end up firing children changed steps, and we get the neccessary changes there (still need to open a DOM PR) that we can do away with the script text entirely and just use invalidation and a trusted boolean "slot".

I'll raise a separate issue to discuss that as that's tangental to this PR itself.

[lukewarlow]

Raised #507 to discuss the "slot" vs invalidation model. Aside from that do the changes to the IDL here make sense?

[annevk]

I think so.

[lukewarlow]

I'm going to go ahead and get this merged, we'll get another chance when I upstream it to HTML to double check it all makes sense within the wider context of the full script enforcement.