Set registry on null registry element on adopt instead of on insert

[ja-y-son]

In order to support scenarios for elements with a null custom element registry without shadow DOM, we decided to modify the behavior when it comes to setting registry on null registry element. By setting the registry on adopt instead of on insert allows us to have null registry element in light DOM while being backwards-compatible.

Fixes #1413 partially. There are two more spec changes expected to add element attribute and allow null registry option during element creation and shadow attachment as mentioned in #1413 (comment)

• At least two implementers are interested (and none opposed):
  • WebKit
  • Chromium
• Tests are written and can be reviewed and commented upon at:
  • web-platform-tests/wpt@cc1c056
• Implementation bugs are filed:
  • Chromium: https://issues.chromium.org/issues/399124619
  • Gecko: https://bugzilla.mozilla.org/show_bug.cgi?id=1874414
  • WebKit: https://bugs.webkit.org/show_bug.cgi?id=302970
• MDN issue is filed: N/A
• The top of this comment includes a clear commit message to use.

(See WHATWG Working Mode: Changes for more details.)

---

Preview | Diff

[ja-y-son]

@rniwa @annevk PTAL, thanks!

Ryosuke, I saw that you have a PR out to support null registry element scenario. Thank you so much for putting those tests together! I'll also go through the current WPTs on my end to see if there are anything else we need to update for these spec changes.

[sorvell]

This matches my understanding of the first set of changes proposed in #1413 (comment) and agreed to at TPAC. Good job!

One minor point: it seems like since insert 7.1 does adopt, perhaps insert 7.7.3.1 and 7.7.4.1 are no longer needed?

[ja-y-son]

@rniwa One thing I'd like to clarify from your PR: One of the test files added is phrased as "append does not upgrade". However, is it correct that we still want to run upgrade during append/insertion steps? It is possible that a null registry element gets a registry when it's appended cross document (which involves adopt steps). In that case we'll want to run an upgrade on the element right? Want to make sure I got the correct understanding here.

[rniwa]

@rniwa One thing I'd like to clarify from your PR: One of the test files added is phrased as "append does not upgrade". However, is it correct that we still want to run upgrade during append/insertion steps?

So regular append should upgrade elements that have a non-null custom element registry. An element with null registry should retain its null registry state and not get upgraded upon insertion.

It is possible that a null registry element gets a registry when it's appended cross document (which involves adopt steps). In that case we'll want to run an upgrade on the element right? Want to make sure I got the correct understanding here.

Yes, in the cross-document append case, we'd first adopt the element to the destination document at which point the null registry will be replaced with the global registry of the destination document.

[ja-y-son]

One minor point: it seems like since insert 7.1 does adopt, perhaps insert 7.7.3.1 and 7.7.4.1 are no longer needed?

@sorvell My understanding is that the scoped document set is used for searching for upgrade candidates in the case of new definition added, so we'll need to keep those two steps around.

[annevk]

Suggested change

	<li>
	<p>If <var>inclusiveDescendant</var> is a <a for=/>shadow root</a>:
	<ol>
	<li><p>if <var>inclusiveDescendant</var>'s <a for=ShadowRoot>custom element registry</a>
	is null or <var>inclusiveDescendant</var>'s <a for=ShadowRoot>custom element registry</a>'s
	<a for=CustomElementRegistry>is scoped</a> is false, then set
	<var>inclusiveDescendant</var>'s <a for=ShadowRoot>custom element registry</a> to
	<var>document</var>'s <a>effective global custom element registry</a>.
	<li><p>If <var>inclusiveDescendant</var> is a <a for=/>shadow root</a> and either
	<var>inclusiveDescendant</var>'s <a for=ShadowRoot>custom element registry</a> is null or
	<var>inclusiveDescendant</var>'s <a for=ShadowRoot>custom element registry</a>'s
	<a for=CustomElementRegistry>is scoped</a> is false, then set <var>inclusiveDescendant</var>'s
	<a for=ShadowRoot>custom element registry</a> to <var>document</var>'s
	<a>effective global custom element registry</a>.

[annevk]

But I think this is incorrect and we still need "keep custom element registry null" here. Have you looked at how the HTML Standard sets "keep custom element registry null"? How is the shadowrootcustomelementregistry content attribute supported in this new world?

[ja-y-son]

In HTML spec where we define the parsing logic for "A start tag whose tag name is "template", we have two repetitive lines describing how shadowrootcustomelementregistry attribute is used:

• If templateStartTag has a shadowrootcustomelementregistry attribute, then set registry to null.
• If templateStartTag has a shadowrootcustomelementregistry attribute, then set shadow's keep custom element registry null to true.

I think we can remove that second line and completely remove the usage of "keep custom element registry null" and we can simply rely on setting the shadowroot's registry to null to support shadowrootcustomelementregistry content attribute behavior.

[annevk]

How do we distinguish the case of a shadow root from a null document registry without the attribute from one with the attribute?

[ja-y-son]

Is it possible to have a DSD with null registry due to shadowrootcustomelementregistry in a null registry document though? Assuming my understanding is correct on "DSD is only created during document parsing and we're not able to get a null registry document during document parsing (has to through JS code like document.implementation.createHTMLDocument();)"

In that case, we can safely assign a registry to null registry shadow root on adopt and remove the need of "keep custom element registry" as we don't assign registry on append regardless.