Re: [whatwg/dom] Introduce `moveBefore()` state-preserving atomic move API (PR #1307)

I definitely understand that. `moveBefore()` appears to be easier to use if it didn't throw any new errors that `insertBefore()`  doesn't already throw. At the same time, there is a predictability cost to this. As I [mentioned over in the Blink I2S](https://groups.google.com/a/chromium.org/g/blink-dev/c/YE_xLH6MkRs/m/ba-KZPUHAQAJ), it might  be weird if `moveBefore()` sometimes had huge side effects like running script, initializing iframes, applying styles, etc., yet other times no side effects at all (because the "atomic" move was carried out).

That said, if 99% of `moveBefore()` uses are from a generic place like a framework, where you _always_ want to move the node from A->B (just atomically when possible!) then the error-throwing behavior becomes cumbersome, because then 99% of users have to call `insertBefore()` from a catch block just to use the API correctly.

I guess it comes down to how often we think people actually care to know whether a truly "atomic" move can be performed, and might act differently if they find out it can't. That's where the error-throwing behavior becomes really useful; without it, if you want to know whether `moveBefore()` will actually move atomically, you have to remember to check [all of the pre-conditions](https://whatpr.org/dom/1307.html#concept-node-ensure-pre-move-validity) before calling `moveBefore()`.

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

Message ID: <whatwg/dom/pull/1307/c2492383530@github.com>