Re: [whatwg/dom] Atomic move operation for element reparenting & reordering (Issue #1255)

trusktr left a comment (whatwg/dom#1255)

> there really isn't much difference between moving within the same parent and giving it a new parent.

There's a big difference.

In the latter (reparenting) it can be a lot more likely that certain code needs to see the reparenting to run logic based on new parent-child relationships (for example such as [updating a WebGL render tree that is outside of the DOM](https://lume.io)).

Re-ordering children of a single parent is less likely to cause downstream state changes, because some important state of the DOM (`.parentElement` and `.children`, etc) remains the same. Sure someone might need to run logic when `.nextElementSibling` changes, but this is more unlikely (I personally haven't seen it, but I don't think the need is zero, just small).

We definitely need to take Custom Elements, MutationObserver, etc, into more consideration, so I'm glad #1270 is tracking this.

We most definitely need to ensure that we update Custom Element and MutationObserver callbacks to account for these new types of mutations, or we will risk mutations being missed. At the moment, for example, a custom element's `connectedCallback` and `disconnectedCallback` currently guarantee that we can observe reparenting _or_ reordering, so if we add these new APIs it is imperative that we do not also cause existing programs to no longer be reactive to DOM mutations.

-- 
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/dom/issues/1255#issuecomment-2660774374
You are receiving this because you are subscribed to this thread.

Message ID: <whatwg/dom/issues/1255/2660774374@github.com>