Re: [w3c/webcomponents] Is there a way to retrieve the localName from a custom element constructor? (#566)

> I'm not comfortable solving this problem only for one class of elements, and making custom elements further special and unique. A lot of the work we're doing in this repository is specifically to ensure custom and built-in elements have the same capabilities, and I'm not OK with breaking that.

@domenic Thanks for summarizing your position.

@rniwa You wrote

> We'd object to adding this functionality for builtins as I've already mentioned during F2F.

I'm sorry, but I can't recall the specifics of that discussion. Can you summarize the objections here?

I ask because I'm still hoping there's room for compromise here, and the more specific the objections are, the higher the chance is that we can find a way to address everyone's concerns.

One strawman compromise: I'm wondering whether we could address this problem at the same time as scoped custom element registries — by representing the built-ins in a new root registry.

The plan for [scoped custom element registries](https://github.com/w3c/webcomponents/issues/716) is to have a new scoped registry inherit from an optional parent registry. E.g., a call to `myRegistry.get` looks in `myRegistry` first, then in parent registries, up to the base `customElements` registry.

I was wondering if we could extend that, and model built-ins in a new element registry called `rootRegistry` (or `allElements`, `globalElements`, or something along those lines).

* The existing `customElements` registry itself would inherit from this new `rootRegistry`.
* A call to `myRegistry.get('div')` or `customElements.get('div')` would eventually defer to the `rootRegistry`, and return HTMLDivElement.
* We could tweak the currently planned constructor for `CustomElementRegistry` so that it _always_ required a `parent` param — if someone didn't want to have the registry inherit from the base `customElements` registry, they would have to pass in the `rootRegistry` as the parent. Alternatively, we could define the latter as the implied default value for a missing `parent` param.

The goal here would be keep the built-ins out of `customElements` (maybe addressing Ryosuke's concerns?), while at the same including those built-ins in a consistent system for mapping tags to classes and vice versa (thereby hopefully addressing Domenic's concerns). By leveraging the planned work for scoped custom element registries, we hopefully keep down costs and end up with a clean model for all elements.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3c/webcomponents/issues/566#issuecomment-545523956