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

I've been asked to discuss the throwing behavior in here but there's really not much else I can add except this new API, desired for many years, is going out in a not-so-usable way, so that user-land libraries are already required to make sense of it at its very current state: https://github.com/ungap/move-before

This makes me sad because there was no real conversation around users' presented use cases and the solution is that "*we*" are landing a new API that requires mandatory `try/catch` around its execution, which is the opposite direction other more recent APIs took, such as `node.remove()`, which works even if the node is not even live.

I fully understand the fact developers might be careful when moving nodes around, but the history of appendChild and insertBefore never cared about any of the guards or guarantees this new API wants to care about (for good reasons) so that having a companion instead of wrapping try/catches all over the Web would've been a better choice than just throwing out of the blue.

As library author, I own my nodes and I know what's live or not, but as my libraries also need to deal with the fact the DOM is shared and accessible by all other libraries out there, there's nothing else I can do than wrap try/catch around this API but I feel like nobody wins this way.

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

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