This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
Many elements have internal state that should be cloned when using `cloneNode()`. From https://dom.spec.whatwg.org/#concept-node-clone: > Run any cloning steps defined for node in other applicable specifications and pass copy, node, document and the clone children flag if set, as parameters. For example in HTML the input element specifies: > The cloning steps for input elements must propagate the value, dirty value flag, checkedness, and dirty checkedness flag from the node being cloned to the copy. This behavior should be hookable by authors as well for their custom elements. My proposal is that we introduce a clonedCallback(source, dest) that, for cloned nodes, is called after the createdCallback with the original as the source and the new clone as the dest. Ideally (probably later) we should also redefine DOM to delegate to clonedCallback instead of to "other applicable specifications" and then HTML should specify the clonedCallback behavior instead of specifying "the cloning steps". That way if you e.g. create a custom element that extends an input element you can call `super.clonedCallback(source, dest)` inside your own `clonedCallback`.
Anne reminded me that my "ideally (probably later)" plan might not work so well for the built-in elements since clonedCallback would likely need to be delayed in some fashion whereas the built-ins try to do everything synchronously. Somewhat-related previous discussion in bug #25529. We should still solve this for custom elements.
> and then HTML should specify the clonedCallback behavior There's a timing difference here, right? The current cloning steps behavior means there are never script-exposed elements that don't have the relevant state propagated yet, while using clonedCallback for this would mean there are. Whether this is a problem in practice probably depends on the element. For example, for a <script> the cloning steps are what propagates the "don't execute again" flag, so this change would allow a single <script> element to execute multiple times...
(In reply to Boris Zbarsky from comment #2) > There's a timing difference here, right? The current cloning steps behavior > means there are never script-exposed elements that don't have the relevant > state propagated yet, while using clonedCallback for this would mean there > are. I don't think so? Note that how custom element callbacks work is that they're copied to an internal registry when you do document.registerElement; it doesn't do a run-time lookup of `theElement.clonedCallback`. So if you envision this as HTML "registering" all its elements ahead of time, the cloned callbacks would be registered with the system ahead of time and couldn't be intercepted or messed with.
*** This bug has been marked as a duplicate of bug 24570 ***
> and couldn't be intercepted or messed with. I'm not talking about interception. I'm talking about interleaving of non-custom and custom callbacks and the fact that the custom ones would be able to observe some already-cloned nodes for which the custom callbacks had not happened yet. Basically, the same issue you mention in comment 1.