Remove the inert document from the HTML fragment parsing algorithm

[foolip]

• Remove the inert document from the HTML fragment parser
• Add a target argument to the HTML/XML fragment parsing algorithms

• At least two implementers are interested (and none opposed):
  • …
  • …
• Tests are written and can be reviewed and commented upon at:
  • …
• Implementation bugs are filed:
  • Chromium: …
  • Gecko: …
  • WebKit: …
  • Deno (only for timers, structured clone, base64 utils, channel messaging, module resolution, web workers, and web storage): …
  • Node.js (only for timers, structured clone, base64 utils, channel messaging, and module resolution): …
• Corresponding HTML AAM & ARIA in HTML issues & PRs:
• MDN issue is filed: …
• The top of this comment includes a clear commit message to use.

(See WHATWG Working Mode: Changes for more details.)

---

/dynamic-markup-insertion.html ( diff )
/parsing.html ( diff )
/xhtml.html ( diff )

[foolip]

This is speculative editing following #11669 (comment) to see what it would mean to remove the inert document from the HTML fragment parsing algorithm.

There are two questions, one small and one big.

Small: Is it necessary to put something on the stack of open elements to not violate assumptions elsewhere? At least Chromium and WebKit put a DocumentFragment on the stack of open elements, but that's not an element. In a quick survey of "stack of open elements" I couldn't find anything that would be broken by letting it be empty, but if there is something perhaps the context element or a shallow copy of it could be placed on the stack of open elements.

Big: What were the side effects of using an inert document that implementations might have achieved in some other way, and that also need to be spec'd?

The main reason for exploring this is to pave way for streamHTMLUnsafe() to simply insert directly into the target node, but it's not strictly necessary, the inert document could be kept around in the definition of existing APIs if it's too risky to change.

cc @zcorpan