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

@domenic not sure you're still ignoring this thread, but worth trying to communicate my (as terse as possible) answer, and I am not speaking for others, just for myself, hoping others agree (with maybe just a thumb up instead of repeated comments):

  1. this was, to me, an opportunity to have a better `insertBefore` story the Web knew so far, meaning, we expected that if any `insertBefore` operation would've worked, no matter the parent/target situation, we expected (probably wrongly so) to "*just work*" and eventually have a stricter flag/third-argument for when the throwing was desired:  `{ fallback: false }`
  2. everyone is interested in the **living DOM** diffing ... I wrote many differs to date and all targeted **living DOM**. I don't think there is out there a single use-case where people would move live nodes into offline fragments (connected -> disconnected), but happy to learn better ... in all my differs, gone nodes are gone, via `remove()` or `parentNode.removeChild(thatOne)`
  3. if the API can cover connected->connected, disconnected->disconnected (even if unusual) and disconnected->connected use cases, I think all libraries would be covered as the diffing is done around the live *parentNode* and rarely, if ever, around some offline fragment
  4. when me (but I guess others too) mentioned *not throwing* I am pretty sure we all meant "*not throwing in all cases where insertBefore would NOT throw too*" ... it wasn't a general *not throwing* argument, it had *insertBefore* as baseline for throwing (attributes,like you mentioned, wrong reference nodes and whatnot)
  5. I would welcome this new API, I am just a bit sad we'll land 2 APIs that do almost exactly the same thing *except one case*
  6. by no mean I ever meant to be against this **huge effort** to add a new primitive to the DOM, and I would like to thank everyone involved, it's just that the final detail, it's name, semantic and English-related understanding of what *move* means in dictionaries, that made me sad such best name, `moveBefore`, will be (speculative) used less in the future than this `moveOrInsertBefore` proposal, because the latter is what most people expects while  the former already needed an amend, regardless the mentioned possibility to have it *opt-in* for throwing as third argument: `{ fallback: false }`
  7. the `if` statement is not the issue, bindings and reaching `Node.prototype` per each `isConnected` out of potentially thousand nodes to *move* is ... somebody already run some benchmark, it's just slower, as slower would be to access for no reason `node.nodeType` per every node that is being manipulated out there

Last, but not least, thanks for your comment and the will to fix users' expectations, in a way or another :heart: 

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

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