- From: Ryosuke Niwa <notifications@github.com>
- Date: Mon, 06 Apr 2020 14:30:20 -0700
- To: w3c/webcomponents <webcomponents@noreply.github.com>
- Cc: Subscribed <subscribed@noreply.github.com>
- Message-ID: <w3c/webcomponents/issues/566/610047252@github.com>
> Per my action item, I spoke to @domenic about this issue. He and I do agree that if we only support custom elements with this API, we're increasing the number of differences between custom elements and built-in elements. That ship has sailed long ago when Google insisted that lifecycle callback can't be sync and that we support non-sync / upgrade for custom elements. Custom elements behave noting like builtin elements today and probably never will given the Web compat. > We have built-in elements, customized built-in elements, and autonomous custom elements. If I'm handed a constructor, it might or might not work with this new API, depending on what it is, and that feels pretty wrong. That's exactly what `customElements.get` does for a custom element name. > @rniwa - I'd be curious to hear whether you disagree with this. In the past, I've seen you arguing pretty strongly for platform consistency. But here you're arguing for **inconsistency** between custom elements and built-in elements. If the argument is just that the proposed API is on `CustomElementRegistry`, then perhaps we could move it somewhere more generic like `Document`? It would definitely be more consistent to have `customElements.getName` which returns the name of a custom element for a constructor given we already have `customElements.get` which implements the inverse function. To begin with, this will be an API on an interfaced named `CustomElementRegistry`. Why we need to care about builtin elements at all in API about custom elements? The point of `CustomElementRegistry` is to query and work with custom elements, not builtin elements. > Having said the above, I do see the obvious developer interest in this capability. We generally support this API, and want to move forward with an _interoperable_ solution. So while we'd prefer to support all constructors, it seems that most/all use-cases center around custom element constructors, so we can go along with an API that only supports custom elements for now. Given there have been no concrete use case presented for retrieving builtin elements' name given their constructors, I don't think supporting builtin elements make sense. -- 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-610047252
Received on Monday, 6 April 2020 21:30:35 UTC