Stream HTML into element or ShadowRoot

[noamr]

Add streaming HTML insertion methods to Element, ShadowRoot, and ChildNode

Introduce safe and unsafe streaming HTML parsing and insertion methods:

• Element & ShadowRoot: streamHTML(), streamHTMLUnsafe(), streamAppendHTML(), streamAppendHTMLUnsafe(), streamPrependHTML(), and streamPrependHTMLUnsafe()
• ChildNode: streamBeforeHTML(), streamBeforeHTMLUnsafe(), streamAfterHTML(), streamAfterHTMLUnsafe(), streamReplaceWithHTML(), and streamReplaceWithHTMLUnsafe()
  This allows developers to parse and stream HTML directly into specific positions of the DOM tree using WritableStream.

The HTML fragment parser is divided into two:

• Preparing the fragment parser (create an inert document with a proper element stack)
• Using that parser to parse into a DocumentFragment

The preparation algorithm is used when streaming, by creating a new fragment parser, and then the stream is routed to feed that parser.

When parsing, the "insertion target redirection map" is configured to reroute insertions intended for the root to go directly into the stream's target element, instead of going into the DocumentFragment.

A special sanitizer mitigation is in place to avoid these removed elements from incurring side effects, by creating them in an inert document if they are about to be removed.

"Scripting mode" has been refactored so that the streaming fragment parser can execute scripts. Instead of relying on the fragment/inert/normal scripting mode, the parser receives a "target document" which is assigned to the script as an "intended document" and checked at preparation time. It is set to the dummy inert document for inert fragment parsing, and to the context document when runScripts is true.

The "fragment case" variants of the parser now check the parser's context element explicitly, rather than relying on
an implicit "this was created by the HTML fragment parser".

Closes #2142

• At least two implementers are interested (and none opposed):
  • Chrome
  • Gecko (HTML streaming & revamped DOM parsing mozilla/standards-positions#1370)
• Tests are written and can be reviewed and commented upon at:
  • Un-tentative streamHTML tests web-platform-tests/wpt#61748
• Implementation bugs are filed:
  • Chromium: Implemented
  • WebKit: https://bugs.webkit.org/show_bug.cgi?id=315741
  • Gecko: https://bugzilla.mozilla.org/show_bug.cgi?id=2043150
• Corresponding HTML AAM & ARIA in HTML issues & PRs: N/A
• MDN issue is filed: Will be done as part of Blink shipping
• The top of this comment includes a [clear commit message

(https://github.com/whatwg/meta/blob/main/COMMITTING.md) to use.

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

---

/dom.html ( diff )
/dynamic-markup-insertion.html ( diff )
/iframe-embed-object.html ( diff )
/index.html ( diff )
/infrastructure.html ( diff )
/interactive-elements.html ( diff )
/parsing.html ( diff )
/references.html ( diff )
/scripting.html ( diff )
/system-state.html ( diff )
/timers-and-user-prompts.html ( diff )
/xhtml.html ( diff )

[zcorpan]

LGTM % spaces

[zcorpan]

ChatGPT re-review

[zcorpan]

The pre-creation mitigation only checks the element name, and it runs after the optional speculative mock-element/fetch operation. Creation-sensitive attributes are still consumed unsanitized: src can reach speculative fetching, is is read before customized-built-in lookup, and the DSD branch reads shadowroot* attributes before generic insertion-time sanitization. A sanitizer that keeps the element but removes one of those attributes can therefore be too late to prevent network, custom-element, or shadow-root side effects. Please sanitize or suppress the relevant token attributes before those operations, with tests observing an actual request, a customized-built-in constructor, and actual shadow-root attachment.

[noamr]

For src, this should not be a problem since this is done in an inert document, and is an existing (non) issue as currently speculative parsing is not sanitized at all.

For is & shadowrootmode, this is a known pre-existing issue and I've added an XXX note in line 146636:

  <p class="XXX">We need to sanitize the template element before applying Declarative Shadow
  DOM. The parser can consult attributes such as shadowrootmode before generic insertion
  algorithms get a chance to sanitize them.</p>

I was going to deal with this in a follow up.

[zcorpan]

The mitigation handles elements that will themselves be removed, but not elements that are kept while a side-effectful attribute is removed. For example, if <img> is allowed but src is not, the element-name check returns Keep, so creation isn't redirected to the inert document. Right?

[noamr]

Ha it's a good catch.
I've update the algorithm to sanitize attributes as the element is created. This fixes is and <img src> (though not <template shadowrootmode> yet).