Re: [whatwg/dom] Declarative Shadow DOM (#831)

Here are some of newly identified issues:

The [serialization algorithm as it currently proposed](https://github.com/whatwg/html/pull/5465) strips away all the default ARIA properties specified on [ElementInternals](https://html.spec.whatwg.org/multipage/custom-elements.html#the-elementinternals-interface) via [ARIAMixin](https://w3c.github.io/aria/#ARIAMixin). This would mean that whenever a custom element is serialized along with its shadow tree, it loses all of its default ARIA semantics. This is a pretty serious show stopper issue.

The serialization algorithm doesn't serialize slots when its shadow host isn't serialized at the same time. This will be extremely inconvenient for things like copying & pasting which, if I remember correctly, was mentioned as one of the motivation for serializing shadow trees.

It's unclear how declarative Shadow DOM will interact with [imperative / manual slot assignment API](https://github.com/whatwg/html/issues/3534) that's currently being worked on. It would be very bad if all slots are treated as name-based and rendered as such initially until scripts are loaded. That would result in a flush of contents between the time declarative shadow DOM is loaded from HTML parser / tree builder and relevant scripts that define custom elements for those shadow hosts are loaded & evaluated.

Finally, it's unclear how declarative Shadow DOM is supposed to work with [adopted stylesheets](https://wicg.github.io/construct-stylesheets/#using-constructed-stylesheets). It would be regrettable if using declarative Shadow DOM prevented using adopted stylesheets or vice versa since people have mentioned in the past that performance as motivating reasons for both features although we remain skeptical to both claims / features as performance improvements.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/dom/issues/831#issuecomment-817259959