Passing the scoped custom element registry to the fragment parser has non-obvious side effects

[noamr]

What is the issue with the HTML Standard?

Currently, the fragment parser uses the custom element registry of its context element when parsing.
(https://html.spec.whatwg.org/multipage/parsing.html#html-fragment-parsing-algorithm step 8)

This has some observable side effects that might not be ideal.
Specifically, the custom element is upgraded and its constructor is invoked at fragment-parse time rather than at connection time.

It is observable in the following scenarios:

• setting innerHTML on a disconnected element with a registry upgrades its custom elements and calls the constructors
• When creating a contextual fragment, the elements are upgraded based on the context but the fragment might be added to a different element in the end
• If there is any change in the registry between parsing time and connection time, the first one wins.
• More acutely - see Custom element registry can call constructor of sanitizer-removed elements WICG/sanitizer-api#381. Elements are upgraded before the sanitizer gets to remove them.

Not sure how to go about this, since it's the only way those element-scoped registries are respected.

[noamr]

Also in general the behavior of an element's scoped registry (without shadow) is really strange IMO...

e.g., the following wouldn't upgrade the element:

const customElementRegistry = new CustomElementRegistry()
customElementRegistry.define("x-element", 
  class MyElement extends HTMLElement { 
    constructor() { super(); console.log("ctor"); }  
  }
);

const doc = new DOMParser().parseFromString("<x-element></x-element>", "text/html")

const container = document.createElement("div", {customElementRegistry});
document.body.append(container);

// The element is adopted and connected, but wouldn't upgrade to anything.
container.append(doc.querySelector("x-element"))

But if you add container.innerHTML = container.innerHTML at the end, it would, because then the "fragment parser takes custom element registry into account" kicks in.

This feels non-obvious and unintuitive to me.

[keithamus]

This is a little related: #12209

[sorvell]

This has some observable side effects that might not be ideal.

I think everything noted here except the interaction with the sanitizer is by design and expected. The registry is determined at construction time and cannot mutate after that, unless it starts as null.

Also in general the behavior of an element's scoped registry (without shadow) is really strange IMO...

The behavior specifically related to adopting elements from different documents is treated specially for backwards compatibility. This means that the behavior of parseFromString and innerHTML is different because in the former case the elements are created in a different document with a null registry. See this example evolved from the parseFromString code above.