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

(For the purpose of brevity, I will begin using the **SPAM** acronym that we've been toying around with internally, which means "state-preserving atomic move". The most obvious example is an iframe that gets SPAM-moved doesn't lose its document or otherwise get torn down).

----

> - Associating with a subtree [...] Basically for a React app we'd just add it to the entire document, but that also affects any subtrees embedded inside the document [...]. It forces us to basically break the whole app to opt into it.
>
> The thing that does causes a change is the place where the move happens.
> [...]
> A new API for insertion/move seems like a better option.

@sebmarkbage I understand your hesitation around a new subtree-associated-HTML-attribute — in that it would be over-broad, affecting tons of nested content that a framework might not own, possibly breaking parts of an app that doesn't expect SPAM moves to happen. But I'm curious if a new DOM API really gets you out from under that over-broadness, while still being useful? What would you expect `orderedList.replaceChildAtomic(newListItem, oldListItem)` to do, where `newListItem` is an `<li>` with a bunch of app-specific (not framework-owned) child content, including `<iframe>`s?

I guess I had in mind that the imperative API would force-SPAM-move the "state-preservable" elements in the subtree that's moving, so that any nested iframes do not get their documents reset[^1]. But if that API would _not_ preserve nested iframe state, then the only way it would be possible to actually preserve that iframe's state in this case is if the application took care to apply an iframe-specific HTML attribute to it, specifying that it opts into SPAM moves:

> - Associating with the node that gets moved e.g. an option on the <iframe> doesn't make much sense because it can be deeply nested inside the tree that moves. [...]

But it sounded like that option didn't sit well with you because the application author would be one-by-one sprinkling these attributes to random iframes without understanding the context in which the SPAM move might actually take place, by a framework way higher up the stack.

So how can we best enable the scenario where an `<li>` that contains a deeply-nested iframe, gets SPAM-moved without the iframe being reset? My thought is that:

- `list.replaceChildAtomic(new, old)` would force-SPAM-move iframes in the `new` subtree (if `new` is already connected in the DOM of course)
- Good ole fashioned `list.replaceChild(new, old)` would only cause SPAM moves to happen on elements in the subtree with the HTML attribute _directly_ applied to it (i.e., `<iframe preserve=content>`), and no other elements.

But I would love to get more thoughts on the subtree side-effects stuff in general.

[^1]: Possibly other state like focus/selection being preserved on other eligible elements; that bit would need to be figured out!

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

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