Scoped Custom Element Registry: Open Design Issues

[leobalter]

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 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 #865 (comment)

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.

[annevk]

As far as I can tell you haven't taken any stab yet at how to modify the define() method to account for custom registries so it's hard to know what part you got stuck on.

The second concern really ties into adoption and associating a registry with a shadow root, neither of which seems to be covered in the draft text. (Most of that would probably end up in the DOM Standard.)

[leobalter]

I tried to get docker working today but everyday is a new bug there.

Unfortunately, I'm yet to re-render the specs to give another read and a better follow up, so my answer here is from my memory recollection.

As far as I can tell you haven't taken any stab yet at how to modify the define() method to account for custom registries so it's hard to know what part you got stuck on.

Yes, this is a subtle change there, where I refer usage to the respective object. e.g. here.

That's why I added this note clarifying the usage targets the given instance where the method is used in, and that could mean either the main customElements or other objects created by the user.

The second concern really ties into adoption and associating a registry with a shadow root, neither of which seems to be covered in the draft text. (Most of that would probably end up in the DOM Standard.)

I tried to address this out here:

 Let document be this CustomElementRegistry's relevant global object's associated DocumentOrShadowRoot.

It's another subtle change, but I was trying to keep up with the observed prose.

---

My goal here is to start small, rather than trying to add too much. I'm not sure yet where I can improve it but I'll take a better look next week when I get through my current issue to run docker and render the page.

[justinfagnani]

After the discussion yesterday, and now that #865 is merged, I think we should open these issues separately:

1. Element constructors, and possible restrictions to only allow a class to be defined in one registry
2. [scoped-registries] Element upgrade ordering #923
3. [scoped-registries] Moving elements with shadow roots between documents #907