W3C home > Mailing lists > Public > public-webapps@w3.org > January to March 2015

Re: Custom element design with ES6 classes and Element constructors

From: Ryosuke Niwa <rniwa@apple.com>
Date: Mon, 12 Jan 2015 16:40:36 -0800
Cc: Anne van Kesteren <annevk@annevk.nl>, WebApps WG <public-webapps@w3.org>
Message-id: <9F6CA67A-6665-4EC7-AE66-50C962FCE905@apple.com>
To: Domenic Denicola <d@domenic.me>

> On Jan 12, 2015, at 4:24 PM, Domenic Denicola <d@domenic.me> wrote:
> From: Ryosuke Niwa [mailto:rniwa@apple.com] 
>> In that case, we can either delay the instantiation of those unknown elements with "-" in their names until pending module loads are finished
> Could you explain this in a bit more detail? I'm hoping there's some brilliant solution hidden here that I haven't been able to find yet.

There's no brilliant solution here.  I'm suggesting to introduce something akin to sync script element.

> For example, given
> <my-el></my-el>
> <script>
>  window.theFirstChild = document.body.firstChild;
>  console.log(window.theFirstChild);
>  console.log(window.theFirstChild.method);
> </script>
> <script type="module" src="my-module.js"></script>
> with my-module.js containing something like
> document.registerElement("my-el", class MyEl extends HTMLElement {
>  constructor() {
>    super();
>    console.log("constructed!");
>  }
>  method() { }
> });
> console.log(document.body.firstChild === window.theFirstChild);
> console.log(document.body.method);
> what happens, approximately?

In this particular example, my-el will remain HTMLUnknownElement since it had already appeared when the script element to load the module is parsed.  A more interesting example would be the one where the script element to load my-module.js appears before my-el.  In that case, the instantiation of my-el is delayed until my-module.js is loaded.

>> or go with option 2
> There are a few classes of objections to option 2, approximately:
> A. It would spam the DOM with mutations (in particular spamming any mutation observers)
> B. It would invalidate any references to the object (e.g. the `window.theFirstChild !== document.body.firstChild` problem), which is problematic if you were e.g. using those as keys in a map.
> C. What happens to any changes you made to the element? (E.g. attributes, event listeners, expando properties, ...)
> I am not sure why A is a big deal, and C seems soluble (copy over most everything, maybe not expandos---probably just follow the behavior of cloneNode). B is the real problem though.
> One crazy idea for solving B is to make every DOM element (or at least, every one generated via parsing a hyphenated or is="" element) into a proxy whose target can switch from e.g. `new HTMLUnknownElement()` to `new MyEl()` after upgrading. Like WindowProxy, basically. I haven't explored this in much detail because proxies are scary.

B is problematic only if authors are not responding to DOM mutations.  If we feel that B is too problematic then we should go with option 1 with the aforementioned synchronous delay.

- R. Niwa
Received on Tuesday, 13 January 2015 00:41:10 UTC

This archive was generated by hypermail 2.3.1 : Friday, 27 October 2017 07:27:25 UTC