Compatibility with new setHTMLUnsafe and parseHTMLUnsafe methods/Declarative Shadow Roots

[shgysk8zer0]

Element.prototype.setHTMLUnsafe and the ShadowRoot equivalent, along with Document.parseHTMLUnsafe have recently landed in browsers, and I assume were at least influenced by what's mentioned here. However, I do not believe I've seen any mention of declarative shadow roots/handling of <template shadowrootmode="..."> here, nor if the following holds true for the "safe" versions here:

The setHTMLUnsafe() method of the Element interface is used to parse a string of HTML into a DocumentFragment, which then replaces the element's subtree in the DOM. The input HTML may include declarative shadow roots.

If the string of HTML defines more than one declarative shadow root in a particular shadow host then only the first ShadowRoot is created — subsequent declarations are parsed as elements within that shadow root.

How will these two intersect? Should/will there be additional options for declarative shadow roots? And, more for curiosity sake, did these unsafe methods originate here or are they separate things?

[otherdaniel]

Spec answer: main sanitize operation, steps 3.4.6: "If child is a shadow host, then call sanitize on child's shadow root".

setHTML, setHTMLUnsafe, and friends call the HTML parsing algorithm and with regards to shadow roots will do whatever that algorithm does. The sanitizer operation will then recurse into the shadow roots, whether open or closed.

If the string of HTML defines more than one declarative shadow root in a particular shadow host then only the first ShadowRoot is created — subsequent declarations are parsed as elements within that shadow root.

I think that is a consequence of how declarative shadow roots are processed; and shouldn't be special for any of the setHTML family of methods. I think this follows from the following spec bits:

• §13.2.6.4.4, In "in head" in insertion mode
• step: "A start tag whose tag name is template"
• step: otherwise
• step: 8 otherwise,
• step 1: "Attach a shadow root [...] If an exception is thrown [...] insert an element with template, and return."

And, more for curiosity sake, did these unsafe methods originate here or are they separate things?

The "unsafe" methods came out of joint discussions involving both Sanitizer API and HTML groups. They were intended as companion methods to their "safe" counterparts.

Some corner stones of these discussions can be found here:

• setHTML() and declarative shadow roots whatwg/html#8627
• Add DOMParser option to parse declarative shadow DOM whatwg/html#8759
• Upcoming HTML standard issue triage meeting on 3/9/2023 whatwg/html#8942
• Add setHTMLUnsafe and parseHTMLUnsafe methods whatwg/html#9538