Web Compatibility of Scoped Custom Element Registries

[annevk]

What is the issue with the HTML Standard?

I stumbled across https://issues.chromium.org/issues/325035505 and the carmax.com issue reproduces in WebKit so unfortunately the new API design still has this problem. Quirking/outreach might be one solution, but maybe more such examples will come up?

cc @karlcow @rniwa @schenney-chromium

[rniwa]

Given this is an issue with Polymer's polyfill which is used on many production sites, I don't think we can quirk it. We should probably rename customElements to something else. Maybe customElementsRegistry.

[annevk]

Sigh. This is why we can't have nice things. I think we should drop the s with the new suffix, i.e., customElementRegistry. If we're going to solve this polyfill nonsense with a rename some more people should probably be in the loop.

cc @smaug---- @domenic @mfreed7 @justinfagnani

[annevk]

For reference: https://github.com/search?q=if+%28%21ShadowRoot.prototype.createElement%29&type=code

[annevk]

We have prototyped a solution that seems to work and preserves the API pretty much as-is (still unfortunate though; please stop polyfilling and deploying polyfills):

• Denote ShadowRoot's customElements with [Replaceable] in Web IDL
• Change the type of ShadowRootInit's customElements member to any and ignore all non-CustomElementRegistry values.

[trusktr]

customElementRegistry

Just in case, if that doesn't work out and a rename has to be done, I'd say elementRegistry is nice. It is very obvious that new elements are "custom", so imo no need to keep the "custom" adjective.

[annevk]

I updated whatwg/dom#1341 to account for this. I'm happy with this resolution so removing agenda+.