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

> > having a moveOrInsertBefore variant (early or soon after) would also work
> 
> my thinking is that having `moveBefore` symmetric with `insertBefore` is the most desired feature so that it's current behavior that will backfire ... but about your use case, what does the developer do once that error occurs? What are the next steps when such move can't be performed? Silently fail on user surfing side or ... what else?

Probably choose a different code path for moving nodes around.
Envision this:

```js
// Option A
new_parent.moveBefore(iframe, ref_node);

// Option B
const fragment = document.createDocumentFragment();
fragment.moveBefore(iframe, null);
new_parent.moveBefore(fragment, ref_node);
```

If we use the fallback version, both of these would succeed and would appear to the developer as if they're doing the same thing, while in fact they have a very different effect to the user.
In the throwing version, the developer would know immediately that if they use (B) this is not going to work, so they have to either try/catch it explicitly or use option A and move the nodes directly.


> 
> **edit** 'cause once again, if we need two APIs to do he same thing I'd rather have the `node.canBeMoved` accessor or method to make those cases obvious witohut needing at all try/catch around.

I have no objections to this.

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

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