"Creating an element" needs to be more precise, for upgrades

[domenic]

In doing 2d07c73 I realized that we need to be more precise on exactly when and how upgrades are enqueued.

@annevk, I could use help figuring this out. Stuff like cloning, for example, needs to enqueue the callback. Its current language seems wrong:

Let copy be a node that implements the same interfaces as node, and fulfills these additional requirements, switching on node:

Are "the same interfaces" just HTMLElement?

What other APIs or parts of specs can create potentially-custom element nodes? So far I can think of:

• cloning
• createElement/createElementNS (already fixed)
• parser (known todo)

Is that really all on the platform?

One way to fix this would be to mint a new "create an element" operation which all of these must call. I guess that doesn't work since the parser and createElement(NS) want to be sync

[domenic]

I guess this is currently handled by the spec's

Whenever an unresolved element is created, it MUST be added to the respective sorted element queue in upgrade candidates map.

Maybe that is as good as we are going to get. On the other hand, if implementers are busy finding all the places in their code this could occur, maybe we should list them in the spec.

[domenic]

No, sorry, I was confusing myself. That clause (currently) only applies to elements created before their definition is registered. It doesn't help with applying upgrade semantics to things like cloneNode when the definition is registered before calling cloneNode but we still want to do the upgrade dance at the end.

[rniwa]

I think we need to define a new spec hook in HTML/DOM when a new element is created, and add a new step to enqueue it for upgrades when the element doesn't match any builtins and has a valid custom element (right set of characters, contains -, etc...).

[annevk]

"same interface" is HTMLEleemnt, Text, SVGElement, HTMLSpanElement, etc. But yeah, I had been thinking that once we get around to this, we need to start upping the level of detail here.

Perhaps we can have a single "create node/element" path that does different things depending on some kind of synchronous flag?

[domenic]

@rniwa can you enumerate all the places you've found that create elements, that would use this hook? Is it just the three in my OP?

@annevk I could try a single hook but I doubt it'll work. It seems like it'll just degenerate into two separate algorithms.

[annevk]

@domenic I think there'll be some shared bits, such as the check for the name. But it might also just be nice for everything else to have a single entry point.

[domenic]

This turned out to work really well. Closing for now until/unless someone gets back to me with more places in the platform that create elements.

• "Create an element": https://w3c.github.io/webcomponents/spec/custom/#dfn-create-element
• Use in cloning: https://w3c.github.io/webcomponents/spec/custom/#clone-modifications-to-dom
• Use in parsing: https://w3c.github.io/webcomponents/spec/custom/#parsing
• Use in createElement(NS): https://w3c.github.io/webcomponents/spec/custom/#extensions-to-document-interface-to-instantiate