- From: Ryosuke Niwa <notifications@github.com>
- Date: Fri, 25 Sep 2020 16:39:12 -0700
- To: w3c/webcomponents <webcomponents@noreply.github.com>
- Cc: Subscribed <subscribed@noreply.github.com>
- Message-ID: <w3c/webcomponents/pull/865/c699219042@github.com>
> @caridy > > > I'm still unclear on how is this different from 1 registry (the global one) vs 10 registries? can you elaborate more? > > The current spec has a definitive order for upgrades. With a scoped registry associated with multiple shadow roots, there are at least two plausible orderings for which shadow roots, and thus which elements, to upgrade first: shadow-including document order, or shadow root creation order (order that shadow roots were associated with the registry). Shadow-including document order is still ambiguous. Some shadow trees may not be connected to a document, and there could be multiple top-level documents in different windows. > > This should not be different to what we do today with the global registry. New entries on those registries can cause upgrades on multiple shadow roots, isn't it? Just like adding a new entry into a scoped registry can cause similar upgrades, in the same fashion, including same ordering. > > We _may_ want to pick the option where we use shadow root creation order because we wouldn't have to walk the entire shadow-including document, we could just visit each associated shadow root and consider only descendants. That seems like a faster choice, though there could be an inconsistency with the global registry if we include disconnected shadow roots. There will definitely be inconsistencies here. > Keeping a list of shadow roots with a registry would create a cycle between shadow roots and registries. I don't know if that's something generally avoided in the DOM, which is why I'm asking for the guidance. So creation order is problematic if we also upgrade elements in disconnected shadow trees because then we end up having to keep all shadow trees that uses the same custom element registry alive (i.e. prevent GC) if at least one of the shadow root has to be kept alive because whether a custom element will be upgraded or not is script observable. This is the exact reason we had to make upgrades only work with connected nodes. -- 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/pull/865#issuecomment-699219042
Received on Friday, 25 September 2020 23:39:25 UTC