This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
Built in elements like inputs have hooks for cloning data that is not represented as children or attributes. Strawman: Add a cloneNodeCallback, which gets called after the element has been called, with a the original element as the context object and the new node as the only argument. Then HTMLInputElement could be implemented as: document.registerElemetn('input', { prototype: { __proto__: HTMLElement.prototype, cloneNodeCallback: function(newNode) { newNode.value = this.value; } } });
Are you also suggesting that browsers refactor their current implementation of <input> to do this copying at the point this callback would normally happen? As currently it happens synchronously. The difference would be observable if you have a mixture of custom and normal elements. A similar question applies to base URL changes in 24577. (I'm assuming when adopting we'll just change the node document of a custom element ourselves.)
Note that this callback should be modeled after http://dom.spec.whatwg.org/#concept-node-clone-ext and take the same arguments. If that is not feasible for some reason I'd like to know why. We should try to refactor that callback to run just before the method call that caused the cloning to return so custom and normal elements have the same processing.
Hmm, HTML's cloning steps for <script> cannot be done from a callback I think. Insertion has already happened at the point the callback is supposed to run and insertion triggers "prepare a script" which checks "already started" which is part of what is to be cloned. So these hooks would not be good for <script>...
I was in a rush when filing this. Conceptually I think we need to be able to explain how the built ins work in this area but I didn't think much about it at the time. I agree that http://dom.spec.whatwg.org/#concept-node-clone-ext is the concept we want to achieve. I'm not sure why you think "insertion has already happened". I think the order would be something more aligned to. New Node - Created Callback Old Node - Cloning Step Callback ... New Node - Attached Callback (if ever inserted into a document) I think the above would work for script. The cloning step would copy the "already started" flag and the attached callback would check if it set. The semantics of this callback would be to call it as a last step of http://dom.spec.whatwg.org/#concept-node-clone and call the callbacks in document order in the cloned tree, passing the old node as the context object and the new node as the only argument (the document can be reached through ownerDocument if needed).
You're right. I was confusing this with adoption. It seems I can get rid of /document/. /clone children flag/ seems to be used by <template>. The callbacks needs to be queued as cloning is also used by range operations and we do not want to run script during those operations I think (but rather just before they return). Queuing them at the current point seems to take care of the recursion automatically.
(In reply to Anne from comment #5) Queuing them at the current point seems to take > care of the recursion automatically. Yup, I believe we can use the same timing as we have for createElement/createdCallback.
Hey guys, Just wondering if this is still on the cards? I'm just running in to similar issues of not being able to hook in to the cloneNode, so curious to see if this will get resolved in the near future or if I should continue to jump through some hacky loops? /Cheers, Jelte
Well, we'll need to sort this out one way or another if we want "Blink-in-JS" and custom elements in general to succeed. So yes.
*** Bug 27420 has been marked as a duplicate of this bug. ***
Moved to https://github.com/w3c/webcomponents/issues/176