- From: Dominic Cooney <notifications@github.com>
- Date: Fri, 03 Jun 2016 00:33:40 -0700
- To: w3c/webcomponents <webcomponents@noreply.github.com>
- Cc:
- Message-ID: <w3c/webcomponents/issues/512/223511006@github.com>
I'm glad you brought this up @rniwa. We should do something for adoption. In the spec today, the current document's definitions are used for finding callbacks, which means element that's moved between documents will pick up callbacks from a definition it never ran the constructor for. > [@domenic's proposal] doesn't make any sense to me. An element doesn't suddenly get un-created just because it got inserted into a new document. Being "un-created" would not happen to the JavaScript object either; the same object would continue to exist. This is similar to the case where an existing element is upgraded: the element existed before it was upgraded and it is the same object after it has been upgraded. It has just been mutated. > calling different constructors twice on the same element seems like an abuse. It does seem odd. On the other hand @domenic 's proposal does make the following case consistent: Say you have document A and document B. Document B has a definition for my-button. I think with the spec today, if you create a my-button in document A and move it to document B, it may or may not get upgraded. It depends on whether document A had a definition for my-button or not. With Domenic's proposal, it's simple and consistent: my-button gets the definition in document B, regardless of what happened to it in the past. > The idea is that we'd provide a callback. @annevk I suppose it is the definition in the original document which gets the callback? That's the only definition that is guaranteed to exist. I think this makes sense. One question I have is running callbacks when the window is gone. If an element from document A is squirreled away somewhere, then A's window is closed/navigated/etc. and later the element is adopted into document B. The document change happens at that point, but it doesn't seem right to be running script from a closed window. It's true script that was already running continues to run after the window is closed, but I'm not sure how readily Blink would start new invocations when there's no window. This was one drawback of the original custom elements spec. Even if you control all of your documents and can register the same definition in all of them, once you close a window/iframe/etc. all of the elements which came from that context stop firing callbacks and are dead in the water. The built-in elements don't work that way. Domenic's proposal does not suffer from these drawbacks because it only relies on the definitions in the new document. --- 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/512#issuecomment-223511006
Received on Friday, 3 June 2016 07:34:10 UTC