Honestly curious - Does anyone have a use case for this? I tried hard to figure out what this could be used for, but couldn't come up with anything.
I'm also thinking about situations where passing accessibility audits is nearly impossible and at odds with business and marketing insisting on complex designs that need to handle a lot of use cases on one page without making the user navigate to another page. Inevitably you find that there's a lot of display state in the DOM you can't serialize, and on the other end of the spectrum simple pages shouldn't need bloated JS web app frameworks just to maintain the state of a form.
For new projects I can see this significantly reducing the JS and CSS needed. Layout change isn't triggered just by screen width but user input state. Right now I see a lot of web projects with ugly CSS (relative positioning or sometimes mind bending stuff with grid/flex) and ugly JS doing error prone element attribute accounting that ultimately wouldn't be necessary if you could just restructure the DOM on the fly.
If you want an example for accessibility, since I think that's usually a big showstopper, many UI designs want z-indexy things such as context menus, tooltips, popups, notifications, modal forms, etc. that would not pass an audit because they're not properly contained within the structure of the page and technically live somewhere rattling around loosely in the <body> with a ton of CSS applied to complete the illusion.
If, instead, you force the user to do things he doesn't want to do in order to get access to the things he wants to do, it's inevitable that the UI becomes frustrating, no matter how much care you put into it.
If your requirements are entirely minimum viable product functional and you don't mind your UI looking incredibly ugly, I agree it is easy.
- move embedded iframe to lightbox for “full screen” and back
- drag and drop of elements without resetting their state
- I’m very curious if it works with contenteditable and/or input method editors. The specifics here are complex so I’m guessing it won’t work, but if it does it will unlock a new bag of tricks for dealing with various problems one encounters when building a rich editor like Notion
Presumably this would also preserve the state of animations, such as GIFs and objects with embedded animated documents (like SVG). With current methods these get reset (along with the already mentioned video state) which break the illusion of an element being transported elsewhere when the original can't be just literally moved.
Could recreate that famous old Mac OS X demo where a video keeps playing while minimized
https://fingswotidun.com/tests/appendNode/
It's interesting that they added new functions to support the new (essentially correct) behaviour. I guess there are people out there that have used moving nodes as a way to delete hidden state.
Much is being made of how it will impact client libraries in other threads, but it's actually driving changes from the server which is most helped by this seemingly simple feature.
To make this real, imagine that you are connected to a collaborative (realtime multi-user) app and someone else drags to reorder an item in a list. Let's say that item has a text box that you're typing into. In today's browsers, all but the most clever implementations will clobber your changes. When this drops, the item you're typing into should be able to be programmatically moved to a different location in the DOM and you won't even lose focus.
That's a big freaking deal that makes server-rendered systems like StimulusReflex, LiveView, Hotwire and HTMX even more desirable options compared to SPAs.
I expect this and the View Transition API to have massive implications for the way libraries are written. And hopefully positive ones. Allowing libraries to "use the platform" more closely