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

@WebReflection those property bags have a GC impact so they can be more expensive than try/catch blocks.
More likely this would look like two versions: `moveBefore` and `moveOrInsertBefore`. It might be OK to deliver both versions in the first go, but we'll have to discuss it with the other browser vendors. The technical complexity of this is negligible, it's just a matter of API design and feature shipping management.

I think the `moveBefore` version that throws has an important use case that's hard to see when we think of this as a drop-in replacement for existing DOM operations. When we introduce move operations, the developer in some cases should be able to *rely* on this being a successful move, not just on "best effort to do something better than before".

For example, your video editing app moves youtube iframes around, and wants to absolutely make sure they're not reloaded during the move. If we use the fallback, this will fail silently and the unexpected outcome would be delivered to the user. If we throw, a change in the user code that breaks the move (e.g. moving via a `DocumentFragment` instead of directly) would throw, alerting the author immediately that their expectation of smooth moves would not be met.

Also when I think about frameworks, they should probably use the throwing version internally (without `try/catch`) when preserving same-document connected nodes, and be careful not to transfer them through a disconnected `DocumentFragment` or element. Passing this responsibility to the framework gives the framework responsibility to know when it's actually moving vs inserted. For small websites that don't use frameworks/DOM libraries, I think `try/catch` is probably fine performance-wise, but as I said having a `moveOrInsertBefore` variant (early or soon after) would also work.


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

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