Re: [w3c/webcomponents] How can a custom element detect when it is transcluded into a shadow tree (slotchange)? (#504)

I think the use case outlined here is an interesting one.  If I understand it correctly, this is really about introducing a new markup language on top of HTML to render 3D graphics like MathML does for mathematical questions and SVG does for vector images.

And I can see that to build something like that, one has to walk across composed/flat tree to see parent/child relationship as they're *presented*.  Unfortunately, I don't think this is something we currently support to be implemented in the author code.  We don't even support using shadow DOM in SVG/MathML context so the scope and usefulness of shadow DOM is quite limited in that respect.

Fundamentally, author code can't see the entire flat / composed tree across all shadow and slot boundaries in the presence of closed shadow trees.  e.g. if `motor-node` is inside a shadow tree A, and its shadow host is assigned to another shadow tree B's slot whose parent is a `motor-scene`, then there is no way for `motor-node` or `motor-sconce` to access one another.

As things stand, you probably need to limit the use of your library to be entirely in a single tree (and not cross any shadow/slot boundaries).  This is an interesting food for thought when we're considering imperative API and more fine grained distribution mechanism in general as well as [Houdini](https://github.com/w3c/css-houdini-drafts/wiki).

---
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3c/webcomponents/issues/504#issuecomment-231664302