Introduce customelementregistry global attribute

[ja-y-son]

Introduce customelementregistry global attribute for elements as discussed in whatwg/dom#1413

• At least two implementers are interested (and none opposed):
  • Chromium
  • Webkit
• 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
• Corresponding HTML AAM & ARIA in HTML issues & PRs: N/A
• 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.)

---

/custom-elements.html ( diff )
/dom.html ( diff )
/index.html ( diff )
/indices.html ( diff )
/infrastructure.html ( diff )
/parsing.html ( diff )

[ja-y-son]

@annevk Here's the PR for the new custom element registry attribute.

[annevk]

Don't we need the same kind of complexity we need as for shadow roots for the same kind of scenario we discussed for them?

[ja-y-son]

Not sure if I followed here. Could you elaborate on the complexity we need for this attribute that you mentioned above?

[annevk]

I think we need a separate "keep custom element registry null" flag for whatwg/dom#1423 (comment).

[ja-y-son]

Added keep custom element registry null concept for the element attribute aligning with the shadowroot counterpart. Also updated whatwg/dom#1437 to include the concept.

[Jamesernator]

This should probably have serialization steps similar to shouldAppendRegistryAttribute for shadowrootcustomelementregistry as well.

[ja-y-son]

@Jamesernator @annevk
I thought about the serialization steps, but when I read through these lines in serializing an element, I thought all attributes are serialized automatically. Am I missing something here?

For each attribute that the element has, append a U+0020 SPACE character, the attribute's serialized name as described below, a U+003D EQUALS SIGN character (=), a U+0022 QUOTATION MARK character ("), the attribute's value, escaped as described below in attribute mode, and a second U+0022 QUOTATION MARK character (").

[Jamesernator]

I thought about the serialization steps, but when I read through these lines in serializing an element, I thought all attributes are serialized automatically. Am I missing something here?

Sure, but calling .createElement('x-foo', { customElementRegistry: nonGlobalRegistry }) doesn't actually set that attribute (besides it could just be removed after as well).

This actually pretty similar to the is attribute in element serialization steps too, in that an element's "is" value is not actually reflected as an attribute. Also like the is attribute we might opt not to emit it if there is already a customelementregistry attribute.

[ja-y-son]

I see what you mean. Then here's an open question on serialization if we expect the attribute to be serialized on element using scoped registry I want to verify here:

<div customelementregistry><foo><bar></bar></foo></div>

const host = document.querySelector('div');
const registry = new CustomElementRegistry();
registry.initialize(host);

In this case, initialize will give foo and bar scoped registry. When we're serializing host, are we expecting to see customelementregistry attribute on foo and bar as well? It feels a bit odd since they didn't have those attribute at the first place.

[Jamesernator]

In this case, initialize will give foo and bar scoped registry.

That depends how foo and bar were created, if they were parsed from the main document then their custom element registry would be the global one anyway so .initialize would be an effective no-op on them.

However if they didn't have a registry then yes I'd expect the change in registry would result in a change in serialization (just like any other DOM change).

[ja-y-son]

I believe the intended behavior of cusomelementregistry attribute is that the element with such attribute and the subtree of the element should all get null registry. The foo and bar in above example should get scoped registry, and it sounds like we do want the attribute serialized for foo and bar.

What if we don’t do the initialize and left foo and bar’s registry null? Should they get the attribute during serialization as well in this case?

[Jamesernator]

I believe the intended behavior of cusomelementregistry attribute is that the element with such attribute and the subtree of the element should all get null registry.

Actually that makes sense, it seems fine to avoid serializing the attribute if the registry is the same as the parent element.

What if we don’t do the initialize and left foo and bar’s registry null? Should they get the attribute during serialization as well in this case?

So I think the serialization is somewhat non-trivial, and we should also carefully consider the possibility of some kind of "declarative custom element registry" in future, with that in mind I think we should go along some lines of:

↓parent \ child→	global registry	custom registry 1	custom registry 2	null
global registry	no attribute	attribute		attribute
custom registry 1	???	no attribute	!!!attribute	!!!attribute
null	???	!!!attribute		!!!no attribute

Ideally we should have some story for global registry as a child of a scoped registry (??? in the table), as both it's not clear how to serialize it, and people transitioning to scoped registries will likely come across places where they need to opt-out.

As a bikeshed perhaps just:

<div customelementregistry="">
    <x-foo></x-foo>
    <div customelementregisty="global">
        <x-foo></x-foo>
    </div>
</div>

Now in the chart I've put !!! in front of entries that, while all could be omitted, may have impacts on a possible future declarative custom element registries. e.g. If in future we have something like:

<customelementregistry specifier="named">
    <define>....</define>
</customelementregistry>

<div customelementregistry="named">
    <div customelementregistry=""></div>
</div>

then those entries with !!! may need special consideration for how it would interact with such a possible feature.

[annevk]

This attribute should also be in IDL.

I'm a bit less concerned about serialization, in particular about combinations you would only be able to end up with after performing tree mutations, such as a global registry child of a custom registry parent. I also don't want to go into the complexity of supporting values at this time as that would also raise questions for the equivalent declarative shadow root attribute.

The one bit of complexity is perhaps that we don't want to add the attribute redundantly I think. If we already serialized it for an ancestor there's no need to serialize it again.

[annevk]

keepRegistryNull

[annevk]

Indentation here is wrong.

[ja-y-son]

If we don't want to over complex the serialization cases, should we consider keeping it to just whichever element has the attribute will get the attribute at serialization. Without considering tree mutation, the elements registry will only be global registry or null due to shadow root attribute/element attribute, and this could be reflected in serialization by serializing the attribute when it presents.

[annevk]

I see the appeal, but I think I'd like to strike a balance where we make some effort to set it when we encounter a node that needs it (and doesn't already have it) and then ignore it for the remainder of that node's subtree.