otherdaniel
commented
2 months ago 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:
Element.prototype.setHTMLUnsafeand the ShadowRoot equivalent, along withDocument.parseHTMLUnsafehave 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: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?