- From: Sasha Firsov <notifications@github.com>
- Date: Thu, 03 Nov 2022 19:06:30 -0700
- To: WICG/webcomponents <webcomponents@noreply.github.com>
- Cc: Subscribed <subscribed@noreply.github.com>
- Message-ID: <WICG/webcomponents/issues/754/1302867804@github.com>
@rniwa , > Sigh... this is the third time I'm having to explain this. Adding the capability to re-define custom elements or delete the definition, we need to https://github.com/WICG/webcomponents/issues/754#issuecomment-557774809. As I have https://github.com/WICG/webcomponents/issues/754#issuecomment-781749398, figuring out how scoped custom element registry would answer most of those questions. The software is soft enough that even craziest things could be done. Just a question of effort. If the polyfiull with good enough performance can be done, it means in native browser it would be done even more efficient. It is not an argument that "difficult to implement" to ban the standard proposal. The proposal can be put on hold with query to provide PR to one of OSS browsers as a proof. Not closed. It is inappropriate that whole range of "must have" patterns been shut down that way. The unregistering custom element is a part of facade pattern which is quite useful in AOP approach of incremental features associations on the component. Those are (but not limited to) * semver support in runtime, * live app upgrade * translation * analytics * ... Note none of the samples are specific to development environment. Those needed in prod. Of course there are work around. And even unregistering can be polyfilled as of now. The question is to keep debate on why needed and how to implement better. Not how to dump brilliant ideas. -- Reply to this email directly or view it on GitHub: https://github.com/WICG/webcomponents/issues/754#issuecomment-1302867804 You are receiving this because you are subscribed to this thread. Message ID: <WICG/webcomponents/issues/754/1302867804@github.com>
Received on Friday, 4 November 2022 02:06:43 UTC