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

> I'm also a bit at a loss as to why we'd discuss new attributes. That seems like a pretty severe layering violation? The way I see it:
> 
> 1. https://dom.spec.whatwg.org/#mutation-algorithms needs to gain a new "move" operation that encapsulates argument validation, new mutation observer records, new callback steps for specifications to hook into, etc.
> 2. We figure out what API is best suitable for that new primitive, e.g., `parent.moveBefore(node, before)`. (Possibly multiple APIs, but best to start small and give it time to bake in multiple implementations.)

I tend to agree with the conclusion, but I want to explain why the main reason to consider things like an iframe attribute, in case it raises something else.

Outside "keep iframes from reloading", it's unclear exactly what the effects of this would be. For focus, we need to blur and refocus anyway, e.g. in case you're moving the element to an `inert` tree. We can decide to do that and just suppress the events. Similar provisions have to be taken for selection. So if we add `moveBefore`, we have to decide if it does all these things, if so, how exactly, or just the iframes thing for start.

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

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