Behavior of `innerHTML` on element with scoped custom element registry

[sorvell]

What is the issue with the HTML Standard?

Elements created via element.innerHTML on an element with a scoped registry do not gain the registry; however, elements created via shadowRoot.innerHTML on a shadowRoot with a scoped registry do.

The intent in #10854 is that Element should support an associated CustomElementRegistry, exposed through a customElementRegistry getter. This impacts elements created through innerHTML and future such methods, such as setHTMLUnsafe(). The current behavior in Safari Technical Preview 221 (example) does not appear to follow this intent. This issue is intended to resolve any spec related concerns.

// element.innerHTML
const customElementRegistry = new CustomElementRegistry();
const div = document.createElement('div', {customElementRegistry});
console.assert(div.customElementRegistry === customElementRegistry, 'via createElement');
div.innerHTML = `<div></div>`;
const child = div.firstChild;
// Fails
console.assert(child.customElementRegistry === customElementRegistry, via element.innerHTML');    

// shadowRoot.innerHTML
const host = document.createElement('div');
const shadowRoot = host.attachShadow({mode: 'open', customElementRegistry});
console.assert(shadowRoot.customElementRegistry === customElementRegistry, 'via attachShadow');
shadowRoot.innerHTML = `<div></div>`;
const shadowChild = shadowRoot.firstChild;
// Passes
console.assert(shadowChild.customElementRegistry === customElementRegistry, via shadowRoot.innerHTML');

[ja-y-son]

Building on top of @sorvell's observation, here're some additional behavior from safari tech preview 221

registry.define('some-element', ScopedSomeElement);
registry.define('other-element', ScopedOtherElement);
const div = document.createElement('div',{customElementRegistry: registry});
// made the following multi-line for the legibility
div.innerHTML =
  '<other-element id="foo">
    <other-element id="bar">
      <div id="baz">
        <other-element id="nested-ce"></other-element>
      </div>
    </other-element>
  </other-element>
  <div id="cool"></div>
  <another-element></another-element>'

It seems like the inheritance (not sure if this is the best term for this) of the scoped registry from the parent div only applies to the direct descendant with defined custom element in the given registry. So, in the above case, #foo, #bar got div's registry, whereas the nested built-in element descendant #baz, nested within another built-in element descendant #nested-ce, built-in element child #cool, not defined custom element child another-element all didn't get the registry from div

[annevk]

This should all follow from https://html.spec.whatwg.org/multipage/parsing.html#create-an-element-for-the-token looking at the parent element when creating a new element in the parser. Coupled with step 7 of https://html.spec.whatwg.org/multipage/parsing.html#html-fragment-parsing-algorithm setting up the root element correctly for fragment parsing.

So it seems all we need here are tests, unless you found an issue with the specification you didn't specify?

@ja-y-son thanks for writing web-platform-tests/wpt#53171. I'll try to review that tomorrow.

[ja-y-son]

I just found that the intended behavior of setting CustomElementRegistry is outlined in the spec already, so I think we're good with the spec.

WPT wise, I realized the test I wrote didn't test against the mentioned buggy behavior (I didn't attempt to set element that wasn't defined in the custom registry in innerHTML), so I'll update it today to make sure we catch the edge cases.