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

Great, thanks for the input @gnoff @infogulch @1cg etc! Here are some of the main points I'm gathering, and some extra thoughts on compat and future extensibility:

1. The code _performing_ the move should decide whether the move is state-preserving atomic or not (not the preservable elements themselves). This tilts things towards an imperative API, which is straight to the point of introducing the new capability, and mirrors existing DOM APIs 🎉
1. For compatibility, whatever API we land on probably needs a way to express the exact breadth of the "preservation" of a SPAM move. This is important when we consider "preserving" things beyond just iframe documents in the future, like input selection/focus, CSS transitions, and for elements that can have _several of these_ preserved/reset during any given move.
    - I think this is important compat-wise, because if you start using `parent.insertBeforeAtomic(div, reference)` to preserve iframe documents in `div`, and then later we introduce the ability to preserve `<input>` selection/focus, we probably don't want `insertBeforeAtomic()` to all of the sudden start preserving `<input>`s inside `div` without your consent.
    - Imperatively, this could look like `parent.insertBeforeAtomic(div, reference, {preserve: 'iframecontent,selection,foo'})`. This ensures the behavior of `insertBeforeAtomic()` doesn't change out from under you as we make more elements/behavior preservable over time.
1. Even with an imperative API, which gives the _mover_ the ability to choose whether to preserve state, there could still be some legacy content deep inside the moved subtree that might not expect state to be preserved during a move. There are a few ways to handle this:
    -  [**Seems most popular**] Do nothing! We don't need to design the API around this; `insertBeforeAtomic()` should always preserve the specified state in the entire moved tree. If you really want to opt out part of the tree from preservation, you can just manually remove & re-insert those things right after `insertBeforeAtomic()`.
    - Add an option to the API that lets you specify portions of a subtree to _not_ preserve: `parent.insertBeforeAtomic(div, reference, {notPreserve: [div.querySelector('.legacy-content-1', …)]})`.
    - Introduce an HTML attribute that can apply to portions of a subtree, which makes `insertBeforeAtomic()` behave like `insertBefore()` for that subtree bearing the opt-out attribute. It sounds like this isn't popular, but I figured I'd just list it for completeness.

Regarding (2) above, if we start by introducing the new API to preserve iframe document state (before we consider other state like selection/focus), we might not want to force users to pass in the clunky options dictionary `insertBeforeAtomic(div, reference, {preserve: iframecontent})`. We could instead just make `insertBeforeAtomic(div, reference)` always preserve iframe content state, and then progressively introduce an options dictionary if we make more state in the future preservable. That way right off the bat, the `insertBeforeAtomic()` API is simple and easy to use, in case we never extend it further for other kinds of state.

Thoughts?

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

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