- From: Joe Pea <notifications@github.com>
- Date: Mon, 31 Aug 2020 13:19:37 -0700
- To: w3c/webcomponents <webcomponents@noreply.github.com>
- Cc: Subscribed <subscribed@noreply.github.com>
- Message-ID: <w3c/webcomponents/issues/893@github.com>
A `shadowattach` event would fire on an element whenever it has a ShadowRoot attached to it (f.e. by calling `attachShadow()` on the element). I believe it can be useful to know when an element's children may be distributed. The main use case is in implementation of non-CSS-based rendering. For example, to implement ShadowDOM support for Mozilla A-Frame, the A-Frame implementation would need to be aware of the final "flat tree" or "composed tree" in order to be able to render the 3D scenes (powered by Three.js) based on the structure of the composed tree. The engine inherently has fully knowledge of the composed tree in order to be able to render everything properly, but userland rendering systems do not have easy access to the composed tree. Adding `shadowattach` event would be a simple way to understand when certain internal state tracking must change in order to update composed rendering. I'm made an initial ShadowDOM implementation for my WebGL-powered elements at http://lume.io, but I'm still working on the edge cases. I've needed to monkey-patch `attachShadow` in order to implement state tracking of the composed tree. I believe that `shadowattach` (or perhaps `distribute` on child elements, or similar) would be one way to update when we know the composed tree may have changed. Basically what I'm thinking about is what features would allows to more easily create custom elements with custom rendering with ShadowDOM support, without requiring monkey patching. `slotchange` is an event that gets us part of the way there, but I found that I can not implement custom rendering only with `slotchange`. Another thing that helps is reading `shadowRoot.host` which only works from the inside of a shadow root if it has `mode: 'closed'`. Another idea is, what if elements had `composedParent` and `composedChildren` properties? This would make it simple to traverse the composed tree. We'd still need events to tell us when these properties change, which can change more often than connected/disconnected. With events, and those properties, we'd be able to easily track the composed tree. -- 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/893
Received on Monday, 31 August 2020 20:19:50 UTC