Atomic move operation for element reparenting & reordering

domfarolino commented 5 months ago

What problem are you trying to solve?

Chrome (@domfarolino, @noamr, @mfreed7) is interested in pursuing the addition of an atomic move primitive in the DOM Standard. This would allow an element to be re-parented or re-ordered without today's side effects of first being removed and then inserted.

Here are all of the prior issues/PRs I could find related to this problem space:

Problem

Without an atomic move operation, re-parenting or re-ordering elements involves first removing them and then re-inserting them. With the DOM Standard's current removal/insertion model, this resets lots of state on various elements, including iframe document state, selection/focus on <input>s, and more. See @josepharhar's reparenting demo for a more exhaustive list of state that gets reset.

This causes lots of developer pain, as recently voiced on X by frameworks like HTMX, and other companies such as Wix, Microsoft, and internally at Google.

This state-resetting is in part caused by the DOM Standard's current insertion & removal model. While well-defined, its model of insertion and removal steps has two issues, both captured by https://github.com/whatwg/dom/issues/808:

Undesirable model: The current DOM Standard allows for the non-atomic insertion of multiple nodes at a time. In practice, this means when appending e.g., a DocumentFragment, script can run in between each individual child insertion, thus observing DOM state before the entire fragment insertion is complete.
Interop issues: While Safari matches the spec, Chromium & Gecko have a model that ensures all DOM mutations are synchronously performed before any script runs as a result of the mutations.

What solutions exist today?

One very limited partial solution that does not actually involve any DOM tree manipulation, is this shadow DOM example that @emilio had posted a while back: https://github.com/whatwg/html/issues/5484#issuecomment-620481794 (see my brief recreation of it below).

Screen Recording 2024-01-29 at 5 00 26 PM

But as mentioned, this does not seem to perform any real DOM mutations; rather, the slot mutation seems to just visually compose the element in the right place. Throughout this example, the iframe's actual parent does not change.

Otherwise, we know there is some historical precedent for trying to solve this problem with WebKit's since-rolled-back "magic iframes". See https://github.com/whatwg/html/issues/5484#issuecomment-619642936 and https://bugs.webkit.org/show_bug.cgi?id=13574#c12. We believe that the concerns from that old approach can be ameliorated by:

Fixing #808, as to not leave elements in a disconnected state at all during the atomic portion of the move (i.e., the re-parenting/re-ordering)
Not allowing atomic moves across documents, which should greatly simplify the security story of this work

How would you solve it?

Solution

To lay the groundwork for an atomic move primitive in the DOM Standard, we plan on resolving https://github.com/whatwg/dom/issues/808 by introducing a model desired by @annevk, @domfarolino, @noamr, and @mfreed7, that resembles Gecko & Chromium's model of handling all script-executing insertion/removal side-effects after all DOM mutations are done, for any given insertion.

With this in place, we believe it will be much easier to separate out the cases where we can simply skip the invocation of insertion/removal side-effects for nodes that are atomically moved in the DOM. This will make us, and implementers, confident that there won't be any way to observe an inconsistent DOM state while atomically moving an element, or experience other nasty unknown side-effects.

The API shape for this new primitive is an open question. Below are a few ideas:

A new DOM API like replaceChildAtomic()/replaceChildrenAtomic() that can take a connected node and atomically re-parent it without removal/insertion side-effects.
- One limitation here is that we'd have to pick and choose which existing DOM APIs we want to mirror with atomic counterparts. For example, if we ever wanted append() or appendChild() to ever be able to also atomically move already-connected nodes, we'd have to introduce appendAtomic() and appendChildAtomic(), and so on.
A setting for existing DOM APIs, e.g., append(node, {atomic: true}), replaceChild(node, {atomic: true})
A scoped, declarative attribute that changes the behavior of DOM mutation APIs in a subtree
- This could be an element attribute that makes all existing DOM mutation APIs behave "atomically" when operating on already-connected nodes under the element's subtree
- This could also be a property on the document overall, set via a header/meta tag, or some other mechanism

Compatibility issues here take the form relying on insertion/removal side-effects which no longer happen during an atomic move. They vary depending on the shape of our final design.

With a new DOM API/setting that developers have to affirmatively opt-into, you could atomically move fragments/subtrees constructed by other library code that's unaware it's being atomically moved. Those fragments may be built in a way that relies on non-atomic move side-effects (though we haven't heard of such concerns directly yet).
Consider an element attribute that changes the behavior of all DOM mutation APIs to behave atomically on already-connected nodes in its subtree. You could minimize compat concerns by externally-constructed portions of the subtree to opt-out of atomic moves with the same attribute. But what would that mean exactly, to have part of a subtree move atomically and part of it not?

A non-exhaustive list of additional complexities that would be nice to track/discuss before a formal design:

How to handle mutation events? There was discussion at the TPAC 2023 about suppressing mutation events when new-ish DOM features are used, so we could probably get away with simply suppressing mutation events whenever an atomic move is being performed??
Handling things like focus/selection properly (need to land on desired behavior)
Fixing up things like live ranges; the way DOM handles this today might already be suitable for atomic moves, but unclear

Anything else?

No response

jarhar commented 5 months ago

你的邮件我已收到，谢

WebReflection commented 5 months ago

First of all, thank you! I've been vocal about this issue about forever and part of one of the biggest discussions you've linked.

As author of various "reactive" libraries and somehow veteran of the "DOM diffing field", I'd like to add an idea:

The API shape for this new primitive is an open question. Below are a few ideas:

I understand a node can be moved from <main> to an <aside> element and this proposal should still work but I think we should not discard the Range API:

most modern libraries have a concept of fragments, inevitably represented as virtual because there's no persistent fragment whatsoever yet on the DOM (I've been vocal about this too)
in a classic table sort mechanism there could be only few TRs moved within a specific place and taht's the same for LIs and others ... if any proposed API consider only parentNode to work that would not satisfy most fragment based requirements where areas are confined within Virtual DOM or comment nodes to confine those special cases while the Range api could instead simply select a node start, a node end, and update atomically inner nodes

On top of this I hope whatever solution comes to mind works well with DOM diffing, so that new nodes can even pass through the usual DOM dance when the parent is changed or they become live, removed nodes that won't land anywhere else would eventually invoke disconnectedCallback if Custom Elements, but nodes already present in that container and moved around basically do nothing in terms of state, they are just shuffled in the layout, if they do.

As quick idea to eventually signal a node is going to be moved in an atomic way, and assuming it's targeting also a live parent, I think something like parent.insertBeforeAtomic(node[, reference]) could be an interesting approach to consider as that basically solves everything, from append to prepend to any other case insertBefore works wonderfully well and it hints that such node should:

do nothing if the parent is the same as before (or the node was already live) ... just move it and skip all the things
trigger connectedCallback if the node was not live
... that's it?

As insertBefore covers append, appendChild, prepend, before and after with ease, it might be the easiest starting point to have something working and useful for the variety of virtual fragments based solutions and diffing APIs out there.

I hope this answer of mine makes sense and maybe trigger some even better idea / API.

edit on after thoughts another companion of the API should be reflected in MutationObserver, or better, MutationRecord ... so far we have addedNodes and removedNodes but nothing about movedNodes which will still be desired for most convoluted edge cases.

The movedNodes record will contain, beside of course the target, a from parent container and a to parent container which might be the same if moved internally but it would signal previous parent and new parent otherwise that something different is within their content.

1cg commented 5 months ago

This would be a fantastic addition of functionality for web development in general and for web libraries in particular. Currently if developers want to preserve the state of a node when updating the DOM they need to be extremely careful not to remove that node from the DOM.

Morphing (https://github.com/patrick-steele-idem/morphdom) is an idea that has developed around addressing this. I have created an extension to the original morphdom algorithm called idiomorph (https://github.com/bigskysoftware/idiomorph/) and the demo for idiomorph shows how it preserves a video in a situation when morphdom cannot. 37Signals has recently integrated idiomorph into Turbo 8 & Rails (https://radanskoric.com/articles/turbo-morphing-deep-dive-idiomorph)

If you look at the details of the idiomorph demo you will see it's set up in a particular way: namely, the video cannot change the depth in the DOM at which it is placed, nor can any of the types of the parent nodes of the video change. This is a severe restriction on what sorts of UI changes idiomorph can handle. With the ability to reparent elements idiomorph could offer much better user experience, handling much more significant changes to the DOM without losing state such as video playback, input focus, etc.

Note that it's not only morphing algorithms like idiomorph that would benefit from this change: nearly any library that mutates the DOM would benefit from this ability. Even virtual DOM based libraries, when the rubber meets the road, need to update the actual DOM and move actual elements around. This change would benefit them tremendously.

Thank you for considering it!

smaug---- commented 4 months ago

Anything else?

Add some complexity to selection/range: how to deal with Shadow DOM when the host moves around and selection is partially in shadow DOM?

ydogandjiev commented 4 months ago

This is a very exciting proposal! In the Microsoft Teams Platform, we extensively use iframes to host embedded apps in the Teams Web/Desktop Clients. When a user navigates away from an experience powered by one of these embedded apps and comes back to it later, we provide the ability for them to keep their iframe cached in the DOM (in a hidden state) and then re-show it later when it's needed again. To implement this functionality, we had to resort to creating the embedded app frames under the body of our page and absolute position them in the right place within our UX. This approach has lots of obvious disadvantages (e.g. breaks the accessibility tree, requires us to run a bounds synchronization loop, etc.) and the only reason we had to resort to it was because moving the iframe in the DOM would reload the embedded app from scratch thus negating any benefits of caching the frame. This proposal would allow us to implement a much more ideal iframe caching solution!

Note the location of the iframe in the DOM and its absolute positioning in this recording: https://github.com/whatwg/dom/assets/3357245/7fd4d2a7-2c2d-4bed-9a78-9c60f26a42f4

infogulch commented 4 months ago

The WHATNOT meetings that occurred after this issue was created deferred discussion about the topic. I wonder what next steps would be needed to move this issue forward. The next meeting is on March 28 (#10215).

noamr commented 4 months ago

The WHATNOT meetings that occurred after this issue was created deferred discussion about the topic. I wonder what next steps would be needed to move this issue forward. The next meeting is on March 28 (#10215).

I hope we can get to it in the 28.3 WHATNOT. @domfarolino @past ?

past commented 4 months ago

It's already on the agenda, so if the interested parties are attending we will discuss this.

iteriani commented 4 months ago

Are the imperative and declarative APIs meant to slowly replace the existing APIs over time? Or do we need to choose between one or the other because of potential overhead?

noamr commented 4 months ago

Are the imperative and declarative APIs meant to slowly replace the existing APIs over time? Or do we need to choose between one or the other because of potential overhead?

If I understand the question, it's mainly for backwards compatibility. In some cases you might want the existing behavior or something subtle in your app relies on it, so we can't just change it under the hood.

sebmarkbage commented 4 months ago

This would be very nice for React since we currently basically just live with things sometimes incorrectly resetting. A couple of notes on the API options:

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. The iframe doesn't know anything about which context it moves inside. At best maybe you'd just have to by default add it to all possible nodes that might contain any state - which is all nodes.
Associating with a subtree creates a kind of "mode". Basically for a React app we'd just add it to the entire document, but that also affects any subtrees embedded inside the document which might be an entire legacy app or a different framework. It forces us to basically break the whole app to opt into it. It'd basically be like a new doctype kind of mode.

The thing that does causes a change is the place where the move happens. But even then it's kind of random which one gets moved and which one implicitly moves by everything around it moving. We don't remove all children and then reinsert them. So sometimes things preserve state.

A new API for insertion/move seems like a better option.

We'd basically like to just always the same API for all moves - which can be thousands at a time. This means that this API would have to be really fast - similar to insertBefore. An API like append(node, {atomic: true}) doesn't seem good because the allocation and creation of potentially new objects and reading back the value from C++ to JS isn't exactly fast. Since this is a high performance API, this seems like a bad option.

Something new like replaceChildAtomic would be easy to adopt inside a library and faster.

rniwa commented 4 months ago

One thing that's nice to nail down is whether re-ordering of child nodes is enough or we need to support re-parenting (i.e. parent node changing from one node to another). Supporting the latter is a lot more challenging than just supporting re-ordering.

1cg commented 4 months ago

Definitely would prefer full re-parenting. I gave an htmx demo of an morph-based swap at Github where you could flip back and forth between two pages and a video keeps working:

https://www.youtube.com/watch?v=Gj6Bez2182k&t=2100s

The dark secret of that demo was that I had to really carefully structure the HTML in the first and second pages to make sure that the video stayed at the same depth w/ the same parent element types to make the video playing keep working. Would be far better for HTML authors if they could change the HTML structure entirely, just build page 1 the way they want and build page 2 the way they want, and we could swap elements into their new spots by ID.

domfarolino commented 4 months ago

(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 doesn't make much sense because it can be deeply nested inside the tree that moves. [...]</li> </ul> </blockquote> <p>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.</p> <p>So how can we best enable the scenario where an <code><li></code> that contains a deeply-nested iframe, gets SPAM-moved without the iframe being reset? My thought is that:</p> <ul> <li><code>list.replaceChildAtomic(new, old)</code> would force-SPAM-move iframes in the <code>new</code> subtree (if <code>new</code> is already connected in the DOM of course)</li> <li>Good ole fashioned <code>list.replaceChild(new, old)</code> would only cause SPAM moves to happen on elements in the subtree with the HTML attribute <em>directly</em> applied to it (i.e., <code><iframe preserve=content></code>), and no other elements.</li> </ul> <p>But I would love to get more thoughts on the subtree side-effects stuff in general.</p> <p>[^1]: Possibly other state like focus/selection being preserved on other eligible elements; that bit would need to be figured out!</p> </div> </div> <div class="comment"> <div class="user"> <a rel="noreferrer nofollow" target="_blank" href="https://github.com/rniwa"><img src="https://avatars.githubusercontent.com/u/285965?v=4" />rniwa</a> commented <strong> 4 months ago</strong> </div> <div class="markdown-body"> <p>I don't think we can make this happen automatically based on a content attribute on an iframe. It most certainly needs to be a completely new DOM API.</p> </div> </div> <div class="comment"> <div class="user"> <a rel="noreferrer nofollow" target="_blank" href="https://github.com/domfarolino"><img src="https://avatars.githubusercontent.com/u/9669289?v=4" />domfarolino</a> commented <strong> 4 months ago</strong> </div> <div class="markdown-body"> <blockquote> <p>I don't think we can make this happen automatically based on a content attribute on an iframe. It most certainly needs to be a completely new DOM API.</p> </blockquote> <p>I am very much open to that, I'm just trying to consider what subtree side-effects are acceptable. That is, if <code>parent.appendAtomic(connectedDivWithChildIframe)</code> should preserve the "child iframe" state or not? I think it has to, for the API to be useful at all. But I'm also sympathetic to compat concerns that it might cause a preserving-move to happen on deeply-nested iframes in a subtree built by another application/framework than the one <em>performing</em> the move in the first place. (And maybe that could break things if parts of the app relies on preserving moves <em>not</em> happening on nodes in the subtree).</p> </div> </div> <div class="comment"> <div class="user"> <a rel="noreferrer nofollow" target="_blank" href="https://github.com/domfarolino"><img src="https://avatars.githubusercontent.com/u/9669289?v=4" />domfarolino</a> commented <strong> 4 months ago</strong> </div> <div class="markdown-body"> <p>An attribute + DOM API could work together in this case a bit, to ameliorate some of the compat concerns. For example:</p> <pre><code class="language-js">const nodeToAtomicallyMove = document.querySelector('......'); // Never trigger atomic moves on *this* specific sub-subtree, that was built by "old" content. nodeToAtomicallyMove.querySelector('.built-by-legacy-app').preserve = 'none'; newParent.appendAtomic(nodeToAtomicallyMove);</code></pre> <p>In this case, all <code><iframe></code>s inside <code>nodeToAtomicallyMove</code> could be SPAM moved <em>except</em> ones that exist inside the subtree <code>.built-by-legacy-app</code>. Those ones are specifically opted-out, because maybe they can't handle preserving-moves... Just an idea!</p> </div> </div> <div class="comment"> <div class="user"> <a rel="noreferrer nofollow" target="_blank" href="https://github.com/rniwa"><img src="https://avatars.githubusercontent.com/u/285965?v=4" />rniwa</a> commented <strong> 4 months ago</strong> </div> <div class="markdown-body"> <p>That sounds like something that could be built by a user hand library, not something that needs to be built into browser's native API. We really need to keep this API proposal as simple & succinct as much as possible.</p> </div> </div> <div class="comment"> <div class="user"> <a rel="noreferrer nofollow" target="_blank" href="https://github.com/noamr"><img src="https://avatars.githubusercontent.com/u/88566?v=4" />noamr</a> commented <strong> 4 months ago</strong> </div> <div class="markdown-body"> <blockquote> <p>I don't think we can make this happen automatically based on a content attribute on an iframe. It most certainly needs to be a completely new DOM API.</p> </blockquote> <p>Can you expand on why this is impossible? I can see the point why it might be preferable, but I think both directions are possible.</p> </div> </div> <div class="comment"> <div class="user"> <a rel="noreferrer nofollow" target="_blank" href="https://github.com/noamr"><img src="https://avatars.githubusercontent.com/u/88566?v=4" />noamr</a> commented <strong> 4 months ago</strong> </div> <div class="markdown-body"> <p>and +1 to not limiting it to reordering. We'll end up just scratching the surface of the use-cases, coming back to where we started where we still need a full solution for reparenting.</p> </div> </div> <div class="comment"> <div class="user"> <a rel="noreferrer nofollow" target="_blank" href="https://github.com/annevk"><img src="https://avatars.githubusercontent.com/u/1544111?v=4" />annevk</a> commented <strong> 4 months ago</strong> </div> <div class="markdown-body"> <p>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:</p> <ol> <li><a href="https://dom.spec.whatwg.org/#mutation-algorithms">https://dom.spec.whatwg.org/#mutation-algorithms</a> needs to gain a new "move" operation that encapsulates argument validation, new mutation observer records, new callback steps for specifications to hook into, etc.</li> <li>We figure out what API is best suitable for that new primitive, e.g., <code>parent.moveBefore(node, before)</code>. (Possibly multiple APIs, but best to start small and give it time to bake in multiple implementations.)</li> </ol> </div> </div> <div class="comment"> <div class="user"> <a rel="noreferrer nofollow" target="_blank" href="https://github.com/noamr"><img src="https://avatars.githubusercontent.com/u/88566?v=4" />noamr</a> commented <strong> 4 months ago</strong> </div> <div class="markdown-body"> <blockquote> <p>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:</p> <ol> <li><a href="https://dom.spec.whatwg.org/#mutation-algorithms">https://dom.spec.whatwg.org/#mutation-algorithms</a> needs to gain a new "move" operation that encapsulates argument validation, new mutation observer records, new callback steps for specifications to hook into, etc.</li> <li>We figure out what API is best suitable for that new primitive, e.g., <code>parent.moveBefore(node, before)</code>. (Possibly multiple APIs, but best to start small and give it time to bake in multiple implementations.)</li> </ol> </blockquote> <p>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.</p> <p>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 <code>inert</code> tree. We can decide to do that and just suppress the events. Similar provisions have to be taken for selection. So if we add <code>moveBefore</code>, we have to decide if it does all these things, if so, how exactly, or just the iframes thing for start.</p> </div> </div> <div class="comment"> <div class="user"> <a rel="noreferrer nofollow" target="_blank" href="https://github.com/gnoff"><img src="https://avatars.githubusercontent.com/u/2716369?v=4" />gnoff</a> commented <strong> 4 months ago</strong> </div> <div class="markdown-body"> <p>@domfarolino </p> <blockquote> <p>I guess I had in mind that the imperative API would force-SPAM-move the "state-preservable" elements in the subtree that's moving</p> </blockquote> <p>I think what Seb is saying is that React can decide if a move should be state preserving but if React added a "preserve-state" attribute to <code><html /></code> and then some embedded application deep in the DOM does an append expecting the append to be non-state-preserving we've just altered the moves that the other application owns.</p> <p>Our perspective is that the mover decides the move semantics rather than the tree. So any moves done by this embedded application won't preserve state b/c that is what the application was expecting and any moves done by React would preserve state becuase React was updated to signal this intent by using a novel API</p> </div> </div> <div class="comment"> <div class="user"> <a rel="noreferrer nofollow" target="_blank" href="https://github.com/sebmarkbage"><img src="https://avatars.githubusercontent.com/u/63648?v=4" />sebmarkbage</a> commented <strong> 4 months ago</strong> </div> <div class="markdown-body"> <p>Although, if it was web-compatible, making it just a breaking change so it's always atomic is even better.</p> </div> </div> <div class="comment"> <div class="user"> <a rel="noreferrer nofollow" target="_blank" href="https://github.com/1cg"><img src="https://avatars.githubusercontent.com/u/469183?v=4" />1cg</a> commented <strong> 4 months ago</strong> </div> <div class="markdown-body"> <p>from an htmx perspective, we have an attribute, <code>hx-preserve</code> that preserves an element in the DOM:</p> <p><a href="https://htmx.org/attributes/hx-preserve/">https://htmx.org/attributes/hx-preserve/</a></p> <p>It does this by looking for "preserved" elements in the new content (fragment) and finding the "old" version in the existing DOM by id:</p> <p><a href="https://github.com/bigskysoftware/htmx/blob/c247cae9bf04b5b274d3bd65937541e8224a359c/src/htmx.js#L887">https://github.com/bigskysoftware/htmx/blob/c247cae9bf04b5b274d3bd65937541e8224a359c/src/htmx.js#L887</a></p> <pre><code class="language-js"> function handlePreservedElements(fragment) { forEach(findAll(fragment, '[hx-preserve], [data-hx-preserve]'), function (preservedElt) { var id = getAttributeValue(preservedElt, "id"); var oldElt = getDocument().getElementById(id); if (oldElt != null) { preservedElt.parentNode.replaceChild(oldElt, preservedElt); } }); }</code></pre> <p>With a new state preserving API we'd update this to something like:</p> <pre><code class="language-js"> function handlePreservedElements(fragment) { forEach(findAll(fragment, '[hx-preserve], [data-hx-preserve]'), function (preservedElt) { var id = getAttributeValue(preservedElt, "id"); var oldElt = getDocument().getElementById(id); if (oldElt != null) { preservedElt.parentNode.replaceChildSPAM(oldElt, preservedElt); } }); }</code></pre> <p>And then all people would need to do to keep, for example, that video playing between pages would be to mark the element as <code>hx-preserved</code>, regardless of what the new content looks like. </p> <p>(Apologies for the <code>forEach()</code> and <code>findAll()</code> methods, they do what you think they do, htmx 1.x is IE compatible so we had to roll our own versions of some stuff.)</p> </div> </div> <div class="comment"> <div class="user"> <a rel="noreferrer nofollow" target="_blank" href="https://github.com/infogulch"><img src="https://avatars.githubusercontent.com/u/133882?v=4" />infogulch</a> commented <strong> 4 months ago</strong> </div> <div class="markdown-body"> <p>I think there are two things here:</p> <ol> <li>The DOM needs a new fundamental capability that it never had before, i.e. <code>insertBeforeAtomic</code></li> <li>If an app is composed from multiple separate components they will need to coordinate around how to use <code>insertBeforeAtomic</code>.</li> </ol> <p>1 must be solved by adding a new DOM api to the spec. IMO, 2 should be the developer's responsibility to manage for now, and adding attributes to allow elements to control how they are swapped should be a separate feature request and discussion.</p> <p>If a page is designed around components that expect some convention wrt how it coordinates use of the new API that's fine, but that doesn't need to be baked into the spec right now, for two reasons:</p> <ul> <li>It dramatically increases the scope of this feature. Just the debate of exactly what the semantics of the attribute should be, how it applies to different node types, etc could burn a lot of time.</li> <li>We don't even know how components will need to coordinate. I don't particularly mind the <code>preserve</code> attribute approach, but I'm not fully convinced that this is the correct API to permanently bake into the DOM either. We've never had <code>insertBeforeAtomic</code> before, so we could just guess what the best API is to coordinate use of it and bake it into the spec and cross our fingers that we got it right, or we could wait until the new feature has some mileage in real apps and consider adding something based on what authors have learned from experience.</li> </ul> </div> </div> <div class="comment"> <div class="user"> <a rel="noreferrer nofollow" target="_blank" href="https://github.com/domfarolino"><img src="https://avatars.githubusercontent.com/u/9669289?v=4" />domfarolino</a> commented <strong> 4 months ago</strong> </div> <div class="markdown-body"> <p>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:</p> <ol> <li>The code <em>performing</em> 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 🎉</li> <li>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 <em>several of these</em> preserved/reset during any given move. <ul> <li>I think this is important compat-wise, because if you start using <code>parent.insertBeforeAtomic(div, reference)</code> to preserve iframe documents in <code>div</code>, and then later we introduce the ability to preserve <code><input></code> selection/focus, we probably don't want <code>insertBeforeAtomic()</code> to all of the sudden start preserving <code><input></code>s inside <code>div</code> without your consent.</li> <li>Imperatively, this could look like <code>parent.insertBeforeAtomic(div, reference, {preserve: 'iframecontent,selection,foo'})</code>. This ensures the behavior of <code>insertBeforeAtomic()</code> doesn't change out from under you as we make more elements/behavior preservable over time.</li> </ul></li> <li>Even with an imperative API, which gives the <em>mover</em> 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: <ul> <li>[<strong>Seems most popular</strong>] Do nothing! We don't need to design the API around this; <code>insertBeforeAtomic()</code> 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 <code>insertBeforeAtomic()</code>.</li> <li>Add an option to the API that lets you specify portions of a subtree to <em>not</em> preserve: <code>parent.insertBeforeAtomic(div, reference, {notPreserve: [div.querySelector('.legacy-content-1', …)]})</code>.</li> <li>Introduce an HTML attribute that can apply to portions of a subtree, which makes <code>insertBeforeAtomic()</code> behave like <code>insertBefore()</code> 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.</li> </ul></li> </ol> <p>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 <code>insertBeforeAtomic(div, reference, {preserve: iframecontent})</code>. We could instead just make <code>insertBeforeAtomic(div, reference)</code> 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 <code>insertBeforeAtomic()</code> API is simple and easy to use, in case we never extend it further for other kinds of state.</p> <p>Thoughts?</p> </div> </div> <div class="comment"> <div class="user"> <a rel="noreferrer nofollow" target="_blank" href="https://github.com/annevk"><img src="https://avatars.githubusercontent.com/u/1544111?v=4" />annevk</a> commented <strong> 4 months ago</strong> </div> <div class="markdown-body"> <p>I would be much more in favor of tackling this once. I.e., go through "remove" and "insert" and collect all the impacted pieces of state and then determine how to handle them for "move". Write expansive test coverage for all the scenarios and then implement, and then write some more tests.</p> </div> </div> <div class="comment"> <div class="user"> <a rel="noreferrer nofollow" target="_blank" href="https://github.com/domfarolino"><img src="https://avatars.githubusercontent.com/u/9669289?v=4" />domfarolino</a> commented <strong> 4 months ago</strong> </div> <div class="markdown-body"> <p>To briefly summarize the WHATNOT <a href="https://github.com/whatwg/html/issues/10215#issuecomment-2025701581">meeting discussion about this issue</a>, we tentatively landed on:</p> <ul> <li>Moving this to stage 1 🎉 </li> <li>Not pursuing an iframe-specific solution, but handling the big known use cases in <a href="https://reparent.jarhar.com/">https://reparent.jarhar.com/</a> up-front</li> <li>Pursuing a generic DOM API that would use a new "move" DOM primitive operation <ul> <li>This API would <strong>not</strong> have a bag of options to specify what kind of state should be preserved, but would preserve all of "the big known things" captured in <a href="https://reparent.jarhar.com/">https://reparent.jarhar.com/</a></li> <li>The compat risk of, in the future, adding possibly-new forms of preservable state that would begin to be preserved by the API, seems "manageable." (The risk of this is at least in part ameliorated by the fact that author JS can opt out of the preservation for any part of any moved subtree, just by removing and re-inserting nodes)</li> </ul></li> </ul> </div> </div> <div class="comment"> <div class="user"> <a rel="noreferrer nofollow" target="_blank" href="https://github.com/WebReflection"><img src="https://avatars.githubusercontent.com/u/85749?v=4" />WebReflection</a> commented <strong> 4 months ago</strong> </div> <div class="markdown-body"> <p>if something like <code>node.moveBefore(...)</code> that mimics <code>insertBefore</code> lands I think this would be huge for the entirety of the Web! thanks for the update, looking forward to see progress or even test, whenever possible, the implementation if you need any extra report/eyes around the diffing side-topic this could solve too.</p> </div> </div> <div class="comment"> <div class="user"> <a rel="noreferrer nofollow" target="_blank" href="https://github.com/pkozlowski-opensource"><img src="https://avatars.githubusercontent.com/u/973550?v=4" />pkozlowski-opensource</a> commented <strong> 3 months ago</strong> </div> <div class="markdown-body"> <p>Catching up with the conversation and adding Angular's perspective here.</p> <p>tl;dr;</p> <ul> <li>very supportive of the effort, definitively see the issues of loosing state when moving DOM nodes around;</li> <li>strongly prefer a new, imperative DOM API (<code>node.moveBefore(...)</code> or similar);</li> <li>not <em>requiring</em> re-parenting in the core of the framework;</li> <li>would like to see general "preserve DOM state" considered and not have it limited to IFrames only;</li> <li>not too concerned with the breaking changes as we see the current non-preserving-state behaviour as problematic - some backward compatibly escape hatch might be useful but not required.</li> </ul> <p>Given the above I think that Angular's position is very well aligned with the <a href="https://github.com/whatwg/dom/issues/1255#issuecomment-2025931322">current direction</a> of the proposal 🎉 </p> <p>Some more details below.</p> <h2>Background</h2> <p>We regularly see issues caused by the "logical move" operation implemented as a pair of remove + add and loosing state as the consequence. This mostly comes up when using loops (<a href="https://angular.dev/api/core/@for">@for</a> or <a href="https://angular.dev/guide/directives#listing-items-with-ngfor">ngFor</a>) that re-order lists - those loops have perfect understanding / distinction of insert vs. move so loosing state with moves is a real concern. We mostly see people complain about state loos in form controls (selection, focus) and iframes. </p> <p>Despite seeing those issues we never attempted implementing any work-around but rather were counting on a solution from the platform - in this sense very supportive of those efforts.</p> <h2>API proposal</h2> <h3>declarative vs. imperative</h3> <p>We mostly move nodes around when re-ordering list items in loops. Those framework constructs are executing JavaScript logic to understand lists re-ordering and move DOM nodes around accordingly. In this sense this logic is already very imperative and thus we would require imperative API to make use of the new platform capability. Declarative attributes could be used to <em>opt out</em> of the state preserving behaviour but using them to indicate that a state of a given node should be preserved would be problematic - we would have to pretty much add those new attributes to all the nodes created by the framework.</p> <h3>API shape</h3> <p>Technically speaking most of the proposed API signatures (<code>parent</code>, <code>parent.insertBeforeAtomic</code>, <code>parent.insertBefore(..., {atomic: true})</code>, <code>node.moveBefore(...)</code> ) would work for us but <code>node.moveBefore(...)</code> seems like a cleanest and preferred shape.</p> <h3>listing state to preserve</h3> <p>We would rather <em>not</em> explicitly list state to preserve as proposed with <code>parent.insertBeforeAtomic(div, reference, {preserve: 'iframecontent,selection,foo'})</code> - this would require us to keep adding new capabilities as they come around, track those and consider breaking changes. Would prefer the approach where we decide, on the platform level on "state that makes sense to preserve".</p> <h3>re-parenting</h3> <p>Not strictly necessary in the core of the framework (we move nodes under the same parent) so could see a 2-phase approach were this simpler use-case is tackled first.</p> <h2>Breaking changes</h2> <p>We do understand that the existing code might somehow depend on the fact that state is reset when the corresponding DOM nodes are moved but we see this more like a bug.</p> <h2>Other comments</h2> <p>The framework is usually moving a set of nodes so would love to see some thinking on this - similar consideration to the one expressed by @WebReflection in <a href="https://github.com/whatwg/dom/issues/1255#issuecomment-1944590622">https://github.com/whatwg/dom/issues/1255#issuecomment-1944590622</a> </p> </div> </div> <div class="comment"> <div class="user"> <a rel="noreferrer nofollow" target="_blank" href="https://github.com/Zlatkovsky"><img src="https://avatars.githubusercontent.com/u/2230453?v=4" />Zlatkovsky</a> commented <strong> 3 months ago</strong> </div> <div class="markdown-body"> <p>I'm a month late to the party, but I too am excited about this proposal! For certain scenarios -- especially ones involving an iframe -- the ability to re-root an iframe could vastly improve perceived performance and overall user experience.</p> <p>For the specific product that I am working on, the specific cases that we are envisioning using this for are:</p> <ul> <li>Primary use-case: load an iframe invisibly in the background (based on a heuristic of the user eventually needing it) so that when the user clicks on a button to view the iframe, we can swap in the already-loaded iframe much quicker than if we were to load from scratch.</li> <li>Secondary use-case: allow moving an already user-visible iframe from one spot in the DOM into another.</li> </ul> <p>Looking forward to seeing this proposal come to life!</p> </div> </div> <div class="comment"> <div class="user"> <a rel="noreferrer nofollow" target="_blank" href="https://github.com/sorvell"><img src="https://avatars.githubusercontent.com/u/78891?v=4" />sorvell</a> commented <strong> 3 months ago</strong> </div> <div class="markdown-body"> <p>I didn't see this explicitly stated so asking directly: is it intended that atomic moves can be observed via APIs like <code>MutationObserver</code> and custom element reactions <code>connected/disconnectedCallback</code>? It seems like this is required to ensure compat. </p> <p>And if so, does the atomic nature of the move need to be exposed somehow? Not sure if it does, but wanted to note that this would probably be easier to do in a <code>MutationRecord</code> than a custom element reaction, but both should be considered.</p> </div> </div> <div class="comment"> <div class="user"> <a rel="noreferrer nofollow" target="_blank" href="https://github.com/annevk"><img src="https://avatars.githubusercontent.com/u/1544111?v=4" />annevk</a> commented <strong> 3 months ago</strong> </div> <div class="markdown-body"> <p>Yes, it needs to be. See <a href="https://github.com/whatwg/dom/issues/1255#issuecomment-2023315861">https://github.com/whatwg/dom/issues/1255#issuecomment-2023315861</a>.</p> </div> </div> <div class="comment"> <div class="user"> <a rel="noreferrer nofollow" target="_blank" href="https://github.com/noamr"><img src="https://avatars.githubusercontent.com/u/88566?v=4" />noamr</a> commented <strong> 3 months ago</strong> </div> <div class="markdown-body"> <blockquote> <p>Yes, it needs to be. See <a href="https://github.com/whatwg/dom/issues/1255#issuecomment-2023315861">https://github.com/whatwg/dom/issues/1255#issuecomment-2023315861</a>.</p> </blockquote> <p>See also #1270 where we track the individual side effects of atmoc moves.</p> </div> </div> <div class="comment"> <div class="user"> <a rel="noreferrer nofollow" target="_blank" href="https://github.com/weizman"><img src="https://avatars.githubusercontent.com/u/13243797?v=4" />weizman</a> commented <strong> 2 months ago</strong> </div> <div class="markdown-body"> <p>This is awesome, my only input here is to kindly ask to remember not to implement this behaviour for when elements cross realms (such as when an element is being reparented under a different document than its current one).</p> <p>I believe this was referred in the descritpion:</p> <blockquote> <p>"Not allowing atomic moves across documents, which should greatly simplify the security story of this work"</p> </blockquote> <p>Which is great, just want to emphasize that this is important from the security angle.</p> <p>Also - cross-document should mean all ways to achieve that, whether by iframe or popups:</p> <pre><code class="language-javascript">const child = document.createElement('a'); document.body.appendChild(document.createElement('iframe')).contentDocument.body.append(child); // OR open('').document.body.append(child);</code></pre> <p>I assume this is clear already, but thought it's worth mentioning. </p> </div> </div> <div class="comment"> <div class="user"> <a rel="noreferrer nofollow" target="_blank" href="https://github.com/noamr"><img src="https://avatars.githubusercontent.com/u/88566?v=4" />noamr</a> commented <strong> 2 months ago</strong> </div> <div class="markdown-body"> <blockquote> <p>This is awesome, my only input here is to kindly ask to remember not to implement this behaviour for when elements cross realms (such as when an element is being reparented under a different document than its current one).</p> <p>I believe this was referred in the descritpion:</p> <blockquote> <p>"Not allowing atomic moves across documents, which should greatly simplify the security story of this work"</p> </blockquote> <p>Which is great, just want to emphasize that this is important from the security angle.</p> <p>Also - cross-document should mean all ways to achieve that, whether by iframe or popups:</p> <pre><code class="language-javascript"> const child = document.createElement('a'); document.body.appendChild(document.createElement('iframe')).contentDocument.body.append(child); // OR open('').document.body.append(child); </code></pre> <p>I assume this is clear already, but thought it's worth mentioning. </p> </blockquote> <p>Thanks Gal, yes the scope of this is same-document moves. Magic iframes are a separate can of worms 🐛.</p> </div> </div> <div class="comment"> <div class="user"> <a rel="noreferrer nofollow" target="_blank" href="https://github.com/aralroca"><img src="https://avatars.githubusercontent.com/u/13313058?v=4" />aralroca</a> commented <strong> 2 months ago</strong> </div> <div class="markdown-body"> <p>I think it's a very good feature, one of the current problems of signals is to manage lists, but with this you could reorganize the lists keeping the signals on it without the need of a diff DOM algorithm right? I love it.</p> </div> </div> <div class="comment"> <div class="user"> <a rel="noreferrer nofollow" target="_blank" href="https://github.com/guillaumebrunerie"><img src="https://avatars.githubusercontent.com/u/787865?v=4" />guillaumebrunerie</a> commented <strong> 2 months ago</strong> </div> <div class="markdown-body"> <p>Great initiative! As a React user, I've encountered two specific situations where the lack of such an API has been an issue, which I hope will be covered by this proposal:</p> <ul> <li> <p>Unexpectedly losing pointer capture when an element in a list gets reordered. Pointer capture is a feature allowing an element to keeps receiving move events even when the pointer moves outside the element, but it is automatically canceled if the element is removed from the DOM. It's natural to use it for elements that can be dragged around, which are also most likely going to get reordered in the HTML. </p> </li> <li> <p>I would like to be able to move a document from an iframe to a separate window open with <code>window.open</code>, and conversely, while preserving all JavaScript state. I'm not sure if this is covered by the "reparenting iframes" use case? This should then ideally be handled automatically by React by simply changing the target of a portal. </p> </li> </ul> </div> </div> <div class="comment"> <div class="user"> <a rel="noreferrer nofollow" target="_blank" href="https://github.com/domfarolino"><img src="https://avatars.githubusercontent.com/u/9669289?v=4" />domfarolino</a> commented <strong> 2 months ago</strong> </div> <div class="markdown-body"> <p>Regarding the pointer capture issue, I want to make sure I understand the scenario. From experimenting <a href="https://output.jsbin.com/moqabap"><strong>with this demo I made</strong></a>, it seems that moving an element around the DOM (with classic <code>insertBefore()</code>, for example) that had <code>setPointerCapture()</code> called on it before the move, results in pointer capturing being <em>reset</em> & the <code>lostpointercapture</code> event being fired. And it sounds like you'd want it to be preserved, and thus the <code>lostpointercapture</code> event would not be fired. Is that right?</p> <blockquote> <p>I would like to be able to move a document from an iframe to a separate window open</p> </blockquote> <p>Our proposal is limited to the same-document move case for now. The cross-document case is significantly more complicated, and most of the big use cases are unlocked with the narrower-scoped approach, so we are starting out with that.</p> </div> </div> <div class="comment"> <div class="user"> <a rel="noreferrer nofollow" target="_blank" href="https://github.com/guillaumebrunerie"><img src="https://avatars.githubusercontent.com/u/787865?v=4" />guillaumebrunerie</a> commented <strong> 2 months ago</strong> </div> <div class="markdown-body"> <blockquote> <p>Regarding the pointer capture issue, I want to make sure I understand the scenario. From experimenting <a href="https://output.jsbin.com/moqabap"><strong>with this demo I made</strong></a>, it seems that moving an element around the DOM (with classic <code>insertBefore()</code>, for example) that had <code>setPointerCapture()</code> called on it before the move, results in pointer capturing being <em>reset</em> & the <code>lostpointercapture</code> event being fired. And it sounds like you'd want it to be preserved, and thus the <code>lostpointercapture</code> event would not be fired. Is that right?</p> </blockquote> <p>Yes, pointer capture itself should stay active and the <code>lostpointercapture</code> event should not be fired. Here is a codepen closer to the issue I was facing: <a href="https://codepen.io/Latcarf/pen/NWXjYNb">https://codepen.io/Latcarf/pen/NWXjYNb</a>. Try to drag around the "Drag me" rectangle and you'll notice that while it’s easy to drag it to the right, it’s pretty hard to drag it to the left (it keeps getting "stuck"). This is because when swapping two children one has to make a choice which one to remove from the DOM and then reinsert. So if we always remove the one on the right (as React does), pointer capture will be lost only when moving to the left.</p> <p>I guess that for this special case we could actually check if the element has pointer capture active and in that case do the swap the other way around (<code>insertBefore(prev, next.nextSibling)</code> instead of <code>insertBefore(next, prev)</code>), but this is not something React does.</p> </div> </div> <div class="comment"> <div class="user"> <a rel="noreferrer nofollow" target="_blank" href="https://github.com/domfarolino"><img src="https://avatars.githubusercontent.com/u/9669289?v=4" />domfarolino</a> commented <strong> 2 months ago</strong> </div> <div class="markdown-body"> <blockquote> <p>This is because when swapping two children one has to make a choice which one to remove from the DOM and then reinsert. So if we always remove the one on the right (as React does), pointer capture will be lost only when moving to the left.</p> <p>I guess that for this special case we could actually check if the element has pointer capture active and in that case do the swap the other way around (insertBefore(prev, next.nextSibling) instead of insertBefore(next, prev)), but this is not something React does.</p> </blockquote> <p>Yep, I had made the same exact code change to your codepen on my own to experiment with. So yeah, while this sort of thing can be worked around by moving <em>different</em> nodes around the DOM with the classic APIs, encouraging this is bad because it just pushes the side effects of state-resetting to other nodes that are further away from the original interaction.</p> <p>It looks like this is all captured in <a href="https://github.com/whatwg/dom/issues/1270#:~:text=Pointer%20event%20state%20reset%3A%20see%20here">https://github.com/whatwg/dom/issues/1270#:~:text=Pointer%20event%20state%20reset%3A%20see%20here</a>, which points to the relevant parts of the pointer events spec (<a href="https://w3c.github.io/pointerevents/#dfn-implicitly-release-the-pointer-capture">example</a>), so I think we're all on track for this!</p> </div> </div> <div class="comment"> <div class="user"> <a rel="noreferrer nofollow" target="_blank" href="https://github.com/anthonyhoegberg"><img src="https://avatars.githubusercontent.com/u/148018847?v=4" />anthonyhoegberg</a> commented <strong> 2 weeks ago</strong> </div> <div class="markdown-body"> <h3>Alternative Suggestion to reparenting/reordering</h3> <p>I hop in here with a suggestion that would replace this but might make the implementation easier.</p> <p>Referencing my other <a href="https://github.com/whatwg/html/issues/5484#issuecomment-1851327170 ">comment </a> on another thread. Instead of reparenting and reordering elements, we allowed something like the <code><slot></code> element to work outside of shadow dom, or create a whole new element whos purpose is to "render" another element inside of itself just like the <code><slot></code> element does. And by <a href="https://developer.mozilla.org/en-US/docs/Web/API/HTMLSlotElement/assign">reassigning</a> the slot or moving around the slot names, we can "move" elements around in dom.</p> <p>We wont actually be moving the elements or effecting the dom three, Just render it in place of the <code><slot></code>.</p> <p>By doing this we wont need to change structure of dom elements or worry about states, three structure etc, since we never move the element just render it somewhere else.</p> </div> </div> <div class="comment"> <div class="user"> <a rel="noreferrer nofollow" target="_blank" href="https://github.com/noamr"><img src="https://avatars.githubusercontent.com/u/88566?v=4" />noamr</a> commented <strong> 2 weeks ago</strong> </div> <div class="markdown-body"> <blockquote> <h3>Alternative Suggestion to reparenting/reordering</h3> <p>I hop in here with a suggestion that would replace this but might make the implementation easier.</p> <p>Referencing my other <a href="https://github.com/whatwg/html/issues/5484#issuecomment-1851327170">comment </a> on another thread. Instead of reparenting and reordering elements, we allowed something like the <code><slot></code> element to work outside of shadow dom, or create a whole new element whos purpose is to "render" another element inside of itself just like the <code><slot></code> element does. And by <a href="https://developer.mozilla.org/en-US/docs/Web/API/HTMLSlotElement/assign">reassigning</a> the slot or moving around the slot names, we can "move" elements around in dom.</p> <p>We wont actually be moving the elements or effecting the dom three, Just render it in place of the <code><slot></code>.</p> <p>By doing this we wont need to change structure of dom elements or worry about states, three structure etc, since we never move the element just render it somewhere else.</p> </blockquote> <p>Thanks! We've actually a similar (or identical) suggestion internally. This requires the author to create a DOM structure especially to support this, e.g. put all the iframes and elements that need to preserve focus as children of the <code>body</code> element (or at the top level inside which they're supposed to be able to preserve focus) and then "ghost" them with slots in their actual DOM locations. Though this might be easier implementation-wise, I think it would create an effect where your DOM structure and your page diverge and it wouldn't be good for authors or the web... e.g. you'd have to account especially for styling (or use <code>::slotted</code>? eek) and <code>document.querySelector</code> and would work totally different way.</p> <p>So I think there are good reasons to push for the direction we're going to which is a DOM operation, that wouldn't require people to make big (or any) adjustments to the semantic structure of their HTML.</p> </div> </div> <div class="comment"> <div class="user"> <a rel="noreferrer nofollow" target="_blank" href="https://github.com/anthonyhoegberg"><img src="https://avatars.githubusercontent.com/u/148018847?v=4" />anthonyhoegberg</a> commented <strong> 2 weeks ago</strong> </div> <div class="markdown-body"> <blockquote> <p>Thanks! We've actually a similar (or identical) suggestion internally. This requires the author to create a DOM structure especially to support this, e.g. put all the iframes and elements that need to preserve focus as children of the <code>body</code> element (or at the top level inside which they're supposed to be able to preserve focus) and then "ghost" them with slots in their actual DOM locations. Though this might be easier implementation-wise, I think it would create an effect where your DOM structure and your page diverge and it wouldn't be good for authors or the web... e.g. you'd have to account especially for styling (or use <code>::slotted</code>? eek) and <code>document.querySelector</code> and would work totally different way.</p> <p>So I think there are good reasons to push for the direction we're going to which is a DOM operation, that wouldn't require people to make big (or any) adjustments to the semantic structure of their HTML.</p> </blockquote> <p>Yeah, i agree with this that having the DOM operation api would be quite nice to work with indeed. I would really love to be able to reorder and reparent elements without their internal states being lost.</p> <p>About the <code>::slotted</code> styling, we could just treat the slotted component as a normal component so if the slotted component is a <code><p></code> element, then the normal styling the slot parent element has for paragraphs should work for that as well (or a flag/attribute to enable this for that slot)?</p> <p>About the change to semantic structure of HTML changing, i at the moment don't have any ideas that would cover this, except recommending that placing the to be slotted elements as close as possible to the place where we use our slots in context with our use case.</p> </div> </div> <div class="comment"> <div class="user"> <a rel="noreferrer nofollow" target="_blank" href="https://github.com/noamr"><img src="https://avatars.githubusercontent.com/u/88566?v=4" />noamr</a> commented <strong> 2 weeks ago</strong> </div> <div class="markdown-body"> <blockquote> <blockquote> <p>Thanks! We've actually a similar (or identical) suggestion internally. This requires the author to create a DOM structure especially to support this, e.g. put all the iframes and elements that need to preserve focus as children of the <code>body</code> element (or at the top level inside which they're supposed to be able to preserve focus) and then "ghost" them with slots in their actual DOM locations. Though this might be easier implementation-wise, I think it would create an effect where your DOM structure and your page diverge and it wouldn't be good for authors or the web... e.g. you'd have to account especially for styling (or use <code>::slotted</code>? eek) and <code>document.querySelector</code> and would work totally different way. So I think there are good reasons to push for the direction we're going to which is a DOM operation, that wouldn't require people to make big (or any) adjustments to the semantic structure of their HTML.</p> </blockquote> <p>Yeah, i agree with this that having the DOM operation api would be quite nice to work with indeed. I would really love to be able to reorder and reparent elements without their internal states being lost.</p> <p>About the <code>::slotted</code> styling, we could just treat the slotted component as a normal component so if the slotted component is a <code><p></code> element, then the normal styling the slot parent element has for paragraphs should work for that as well (or a flag/attribute to enable this for that slot)?</p> </blockquote> <p>This would open up a whole bag of worms in terms of complexity because the slotted element would now be styled based on two locations...</p> <blockquote> <p>About the change to semantic structure of HTML changing, i at the moment don't have any ideas that would cover this, except recommending that placing the to be slotted elements as close as possible to the place where we use our slots in context with our use case.</p> </blockquote> <p>Right... I think having a <code>slot</code> outside of shadow-DOM is not a bad idea in itself but for the above reason it doesn't replace <code>Node.prototype.moveBefore</code>.</p> </div> </div> <div class="comment"> <div class="user"> <a rel="noreferrer nofollow" target="_blank" href="https://github.com/anthonyhoegberg"><img src="https://avatars.githubusercontent.com/u/148018847?v=4" />anthonyhoegberg</a> commented <strong> 2 weeks ago</strong> </div> <div class="markdown-body"> <blockquote> <p>This would open up a whole bag of worms in terms of complexity because the slotted element would now be styled based on two locations...</p> </blockquote> <p>What about not rendering the element at, only when it is slotted? Kind of like a template just to let the element live somewhere but be rendered elsewhere. So the style will only be based in one location where it is slotted? (Maybe the slotted conversation should be done elsewhere? I love slots so if there is a appropriate place to have this conversation please tell me.)</p> <p>Even if slotted is updated/changed to be able to be used outside of shadow-DOM i still think that <code>Node.prototype.moveBefore</code> etc should be implemented.</p> </div> </div> <div class="comment"> <div class="user"> <a rel="noreferrer nofollow" target="_blank" href="https://github.com/noamr"><img src="https://avatars.githubusercontent.com/u/88566?v=4" />noamr</a> commented <strong> 2 weeks ago</strong> </div> <div class="markdown-body"> <blockquote> <p>Even if slotted is updated/changed to be able to be used outside of shadow-DOM i still think that <code>Node.prototype.moveBefore</code> etc should be implemented.</p> </blockquote> <p>I agree, it's a worthwhile and separate feature! Would you mind opening a separate issue on the HTML repo for this?</p> </div> </div> <div class="page-bar-simple"> </div> <div class="footer"> <ul class="body"> <li>© <script> document.write(new Date().getFullYear()) </script> Githubissues.</li> <li>Githubissues is a development platform for aggregating issues.</li> </ul> </div> <script src="https://cdn.jsdelivr.net/npm/jquery@3.5.1/dist/jquery.min.js"></script> <script src="/githubissues/assets/js.js"></script> <script src="/githubissues/assets/markdown.js"></script> <script src="https://cdn.jsdelivr.net/gh/highlightjs/cdn-release@11.4.0/build/highlight.min.js"></script> <script src="https://cdn.jsdelivr.net/gh/highlightjs/cdn-release@11.4.0/build/languages/go.min.js"></script> <script> hljs.highlightAll(); </script> </body> </html>

whatwg / dom