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

@domfarolino commented on this pull request.



> + <li><p>Let <var>return node</var> be the result of <a>pre-inserting</a> <var>node</var> into
+ <a>this</a> before <var>child</var>.</p></li>

I thought about this a bit more. I think we're happy to create a new "move" primitive algorithm following the "insert" and "remove" algorithms. As you mentioned, it will be a simpler algorithm than "insert" since we'll avoid the `DocumentFragment` stuff — oh and also the post-connection stuff, among maybe more things.

There's still the discussion around introducing either (**a**) new "move" steps/hook that other specs provide to react to moves, vs (**b**) a Document-scoped boolean that the new "move" algorithm sets, for existing insertion/removal steps to use, to not reset certain state inside those steps.

Option (b) is the direction of the current PR, which we think makes sense after implementing this in Chromium. I think this is because so far we've found no behavior that we specifically want to do during a move that isn't done by insertion/removal — so any "move steps" we provided would just be empty. **Does that make sense?**

Now, I think the real question here is whether we want to:

1. Keep running the [insertion](https://dom.spec.whatwg.org/#concept-node-insert-ext)/[removal](https://dom.spec.whatwg.org/#concept-node-remove-ext) steps during a "move" operation, and just pepper `if during atomic move is true, don't run some of these substeps!` wherever state would ordinarily be reset
    - Cancel out [the iframe removal steps](https://html.spec.whatwg.org/C#the-iframe-element:html-element-insertion-steps)
    - Cancel [img relevant mutations](https://html.spec.whatwg.org/C#reacting-to-dom-mutations:html-element-insertion-steps), to avoid re-firing load events
1. Simply not run insertion/removal hooks _at all_ during a move. This is only feasible if we determine that there are absolutely no steps in any spec's existing insertion/removal hooks that need to run during a move. We'll have to do an audit to determine this, which I'm starting now.

So the way I see it, those are probably our options, as opposed to creating new move steps which I think from our findings so far, would be unused. (We'll course-correct if this finding changes).

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

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