Re: [whatwg/dom] Proposal: moveOrInsertBefore() (Issue #1406)

justinfagnani left a comment (whatwg/dom#1406)

> I think we just disagree. Moving is not an implementation detail. If you think it should be, I recommend not using the move primitive at all and always use the APIs that disconnect and connect.

I think this stance is overlooking the use case here. This isn't a direct call to `.insertBefore()` or `.moveBefore()` - this is general code for moving DOM nodes (ie, reordering a list) that would prefer to preserve as much DOM state as possible and currently has an unfortunate choice to make:

1. Not try to help preserve DOM state at all and partially lose state depending on which moves were made - only some animations stop, some iframes reload, focus and selection are lost only sometimes, etc.
2. Try to preserve state on specially marked elements by moving everything _but_ those elements, if you can. You still lose state on everything else, but focus, etc., is at least preserved on one thing. This requires a lot of code.
3. Special-case and automatically preserve some state, like focus and selection. Requires more code (and frameworks often don't support shadow DOM correctly) and doesn't work in closed shadow roots, etc.
4. Use `moveBefore()`, but re-implement its gating logic, or use a try/catch around it to fallback to `insertBefore()`. This is better than (1), (2), and (3), for sure.

There is no options in this use case where a library would call `moveBefore()` and _not_ fall back to `insertBefore()`. `moveBefore()` is almost strictly better, except that it throws sometimes. `moveOrInsertBefore()` _would_ be strictly better.

I understand that there theoretically could be compat issues if the move conditions change in the future, but note that this is already the case. If framework code just does:

```ts
function moveOrInsertBefore(container, node, refNode) {
  try {
    container.moveBefore(node, refNode);
  } catch (e) {
    container.insertBefore(node, refNode);
  }
}
```

Then any change to the move conditions will cause the same class of webcompat issues - it will change which nodes may move or not.

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

Message ID: <whatwg/dom/issues/1406/6474342290@github.com>