[w3c/webcomponents] Spec Review: Open Design Issues (#895)

While we've been discussing about Scoped CustomElementRegistry (see #865) there are some orthogonal issues that we might want to resolve to clear the path to properly draft a spec text for the given proposal. I'm trying to set a proper plan here.

I'm relatively new to the prose in the HTML Standards, at least as authoring spec text. I [started some work here](https://github.com/leobalter/html/pull/1) but as I understand from @rniwa we could address some current design issues highlighted in the proposal. 

So far I can point those issues to _upgrade ordering & multiple documents_ as seen in the comment below, but I'd like a better direction how to tackle them in the specs.

@rniwa @justinfagnani @annevk @caridy, I would appreciate your input here.

---

_Original post from @rniwa at https://github.com/w3c/webcomponents/pull/865#issuecomment-700585737_

> I was thinking the global one could do shadow trees with their own registry more quickly, but it depends a bit on nested shadow trees and might require more bookkeeping than it's worth. It does seem like you want that to be fast as well though since not all elements will be nested in a shadow tree.

Well, you'd need nested shadow trees to be ordered so you kind of need to either cache the ordering or traverse through them anyway. The only work you're gonna avoid for free will be leaf shadow trees or shadow trees in which there are no more than one nested shadow tree which uses the global registry. But that's easy enough of an optimizations to add regardless of what we do with scoped registries. It would be really shitty if we had to traverse through the entire document to figure out which shadow tree comes first each time upgrading step needs to run in `define` call.

> If a registry is bound to a document and you move a shadow root associated with a registry to another document, I would assume we want that shadow root to lose its connection to the registry. I suppose we could also make a bunch of things no longer work, but either way you should be able to recover from that I think (by associating the shadow root with an equivalent registry for that document). For elements we offer `adoptedCallback`, for shadow roots we don't have such a thing. So either we'd add something to shadow roots or we tightly couple these kind of shadow roots (that have a custom registry) to elements that can have custom internals.

What do you mean by "lose its connection"? Meaning that things like innerHTML will no longer work? That's sort of in line with what I was suggesting earlier but for this recovery thing to work, we'd need to make it possible to re-associate a shadow root with a new scoped registry after the fact. That seems like a new complication to me.

Overall, there is a lot of open questions with regards to upgrade ordering & multiple documents.


-- 
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/895