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

> 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).

if everyone will inevitably end up using a `try/catch` that fallback to `insertBefore` this API throwing doesn't help at all + all checks [mentioned in here](https://github.com/whatwg/dom/pull/1307#issuecomment-2491906616) are not obvious, developer friendly, or performance friendly.

When a developer does not want to have side-effects it can perform those checks manually, the rest 99% of the world will just `moveBefore` and fallback to `insertBefore`, including all frameworks, hence my question: who is this throwing behavior helping and why an alternative solution such as `parent.canMoveNode(node)` has not been discussed, as that would do surely the right thing internally as opposite of asking developers to know what are all conditions to check before a node can be moved or not?

Please note I am not suggesting `canMoveNode` together with a throwing `moveBefore`, I am suggesting a `moveBefore` that tries to do the right thing and fallback to `insertBefore` without throwing, plus a `canMoveNode` for anyone interested in that detail (which is niece, or tests based things, or perf based things, or debugging based things).

In short, if try/catch is the workaround, everyone will use it and all the reasons it couldn't be done behind the scene in the name of "*it's better for developers*" will be futile, I hope we can agree on that.

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

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