<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Jul 21, 2017 at 10:24 AM, Andreas Plesch <span dir="ltr"><<a href="mailto:andreasplesch@gmail.com" target="_blank">andreasplesch@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br><div dir="ltr">...<div>It could also be fruitful to investigate how custom elements with templates compare with protos in detail. There seems to be match in purpose and ability.</div></div></blockquote><div><br></div><div>I investigated a bit more how to use web components' slotted templates with x3dom. Slots are placeholders inside templates which can be assigned content. The assignment works only when a template is used in a shadow root. The shadow host can provide the content for the slots. It turns out that there are too many obstacles to make this approach to macro's or protos viable. First, the shadowing disrupts the parent-child relationship between shadow host (a group or transform) and the template in the shadow root. The shadow root is intentionally a root of a new document fragment. Second, the shadow DOM does not actually change when the slots are populated. The slot elements merely get an additional assignedNodes property which the web browser automatically uses to render if it knows how to. x3dom has this responsibility and would need to know how to deal with slots explicitly. Here is a related discussion:  <br></div><div><br><a href="https://github.com/w3c/webcomponents/issues/611">https://github.com/w3c/webcomponents/issues/611</a><br><br></div><div>A-Frame and other libraries are similarly affected. A-Frame does not support shadow DOM use.<br></div><div><br></div><div>It may be possible to process the attached and populated template to replace slot elements with their corresponding assigned nodes. This leaves the first problem or parenting (a universal one !). One solution may be to move the shadow root nodes out and into the light dom under the shadow host. This defeats encapsulation. One still gets the templating but overall this approach will only work if web browsers would understand how to render x3d natively. At this point I think it is even difficult to do this with svg.<br><br></div><div>-Andreas<br></div><div><br></div></div></div></div>