> On Jan 12, 2015, at 4:24 PM, Domenic Denicola <d...@domenic.me> wrote:
>
> From: Ryosuke Niwa [mailto:rn...@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
