Revamped Scoped Custom Element Registries (DOM side)

[annevk]

This is a sibling issue of whatwg/html#10854. Discussion of the proposal should probably go there, but for any niche concerns pertaining the DOM side this would be a good place to put them.

Some recent work I did such as 7801c9d is paving the way for this feature.

[annevk]

• Should isEqualNode() care about the registry? It has to ignore the null registry (at least when comparing with the global registry), but otherwise it could compare it and arguably should. (It was decided it should not.)
• When we insert an element, do we want to go through its entire subtree and append the current document to each of the non-null registries's scoped document sets? I guess so, since this might be the first time each of those registries gets used. This is not specified in the current draft.
• Should we also append root's node document in initializeSubtree()? I suspect so. Where else? Not sure I have a good feel for the rule here.
• rniwa suggested moving "active custom element constructor map" to the agent, which seems reasonable.
• Does element.innerHTML upgrade elements even when element is disconnected? Might have some implications for when we want to update the registry when inserting nodes.

[sorvell]

What happens when an element is inserted from another document?

Today it is upgraded with the adopted document's registry. It seems like since these elements would generally have a specified customElements, they would not upgrade? If so, this would likely introduce a compatibility issue.

[annevk]

In most scenarios those other documents don't have a browsing context so will end up with a null registry, but for iframe and such there would indeed be a change in behavior for elements that haven't upgraded yet. We'd have to experiment with that, but one solution if it's problematic would be to reset non-scoped registries of non-upgraded elements as well. A bit ugly, but not the end of the world.

[sorvell]

The common case here is definitely legacy code that does template.content.cloneNode(true) so if those are null and become the insertion registry, this makes sense.

Implementation concern: My understanding is that there's a strong desire to avoid initializing the customElements getter in the common case, but if it default to window.customElements but in the template cloning case it would be null, that has to be initialized. I think this is a very common way frameworks create DOM.

For cross-document un-upgraded nodes with a customElements set, my concern is that generally these elements have their backing class changed to the adopting document's HTMLElement so either this has to be accounted for or they would fail to upgrade in any registry from their initial document. Perhaps all un-upgraded elements should have their registry set to null on adoption?

[annevk]

As I mentioned elsewhere rniwa and I looked at avoiding the null state, but it's not possible.

I don't really understand your cross-document concern. If it's not upgraded, but has a registry, we can upgrade it through that registry. We don't use JS instanceof if that's your concern. We use a mostly internal cross-realm variant (throughout the web platform, I might add).

[sorvell]

I don't really understand your cross-document concern.

Just hoping to ensure we're covering it well. Mostly I wanted to make sure template cloning would be ok since this is a framework hot path, but we've also seen a surprising interest in moving custom elements between documents, e.g. with the PIP api.