From a9e8c849b7c25c08705ecec1aff871b2e274e694 Mon Sep 17 00:00:00 2001 From: Jeff Rescignano Date: Tue, 5 Jan 2021 04:02:59 -0500 Subject: [PATCH] Update Scoped Elements URL from 2020-10-02 Blog Post (#762) --- blog/2020-10-02-lazyMoreInfo.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/blog/2020-10-02-lazyMoreInfo.md b/blog/2020-10-02-lazyMoreInfo.md index 32ef7df5..ad05821d 100644 --- a/blog/2020-10-02-lazyMoreInfo.md +++ b/blog/2020-10-02-lazyMoreInfo.md @@ -45,7 +45,7 @@ We use external custom elements in our frontend, like the [Material Web Componen Just like our own elements the external elements are part of our code splitted chunks, and they will probably be lazy-loaded. That means they will not be available at all times but could be loaded later. This means that if a custom card would load and define an `mwc` element because it was not available at the time it needed it, and we try to do it later when it is lazy-loaded, the Home Assistant frontend will run into an error. -Unfortunately, there is no technical solution for this at the moment. There are some solutions, like [scoped elements](https://open-wc.org/scoped-elements/) from open-wc, but they will not work in most cases as the imported element will either self-register or it defines sub-elements, that can not be scoped. +Unfortunately, there is no technical solution for this at the moment. There are some solutions, like [scoped elements](https://open-wc.org/docs/development/scoped-elements/) from open-wc, but they will not work in most cases as the imported element will either self-register or it defines sub-elements, that can not be scoped. There is a discussion about a proposal for [Scoped Custom Element Definitions](https://github.com/w3c/webcomponents/issues/716) that could potentially fix this problem, but it may take a long time before this would be available in all our supported browsers, if the proposal is accepted at all. ## Is there a solution?