In typical Chrome fashion, they shipped an API that is in status "Specification currently under development in a Working Group"
I don't understand the need for this awkward API.
Ok, `otherParent.append(existingIframe)` reloads the iframe, but that's just a legacy behavior. Why not toggle the new behavior by calling `existingIframe.holdMyBeer()`? This way I could just continue using .prepend/.append/.before/.after et — which by the way support multiple elements at once, unlike moveBefore.
Ridiculous choice, but I'm not even surprised anymore.
> I don't understand the need for this awkward API.
Well, it's clear you didn't take the time to try. There are multiple threads on this and related topics, with inputs from all browser vendors.
This has been a high-priority standards request from framework and rendering library maintainers for many, many years. Chrome is not at all being ridiculous.
The biggest benefit to this is that it makes one of the slowest parts of virtual DOM diffing (longest common subsequence) no longer required. After this becomes supported in the mainstream, not even signal-based frameworks will have to include VDOM algorithms. I know this because I remember pushing for this to be supported a few years ago — a nice reminder that the standards are evolving and that nothing stops you from being a small part of the effort.
Next up — DOM parts and standardized signals, unified.
How do you even bring this up in a way that it gets noticed by the right people? There's so many times I read niche parts of the DOM that I feel need serious enhancements. I use Blazor (WASM) a lot more these days, so a lot of that is masked from me now.
VDOM hasn't been needed for a long while, if ever.
You can do a lot better just checking if the template that/s rendering to a spot in the DOM is the same or different from the previous template. If it's the same, just update the bindings from the template, if it's different re-render the whole thing.
That's simpler and faster, but the one thing it leaves out is stateful reordering of lists. So you can have a specific re-ordering code path, which is simpler than a full VDOM, but if you want to preserve state like moveBefore() does, even that reordering gets pretty complicated because you can only preserve state for one contiguous range of nodes that you don't actually move - instead you move all the other nodes around them. moveBefore() just eliminates all that extra complexity.
There's also a couple of standards issues open for native reordering of siblings, like reorderChildren(). That would eliminate the re-ordering code completely.
I'm not exactly sure what the developer experience of this would be, but I expect it would make Portals significantly more powerful and able to be hot-swapped into different containers without disrupting either their internal state or even things like loaded iFrames. I expect others will be experimenting heavily with this now that there's platform support.
I'm the developer of react-reverse-portal, this will definitely be a real help!
Iframes particularly have always been a pain point, as people often want to reparent them to move things around the DOM, but they always reload completely when you do so which causes all sorts of issues. This new API says it explicitly _doesn't_ reload iframes, so we'll be able to drop that caveat immediately (for supporting browsers, but hopefully Safari/FF will follow suit soon). Looks great!
Also great for rich interactive experiences that use traditional server side rendering to a large degree, this would allow you to make something like the Spotify web application without the need for large client side heavy JavaScript to render things.
It's stage 3... and "the existence of stage 4 is basically a formality"
> [stage 3] basically means "finished, pending editorial nit review---but since multiple implementations haven't happened yet, there's a reasonable chance that we'll discover something is broken, and need to fix the normative content
Wow! This is actually an amazing feature. Rendering a list of items in which the order can change has always been annoying. I can see this feature greatly improving the situation.
Previously if you moved an element anywhere else in the DOM for any reason - such as reordering elements, sorting a list, etc. - lots of kinds of elements would be reset: iframes reloaded, transitions/animations are cancelled, video playback is reset, focus is lost, even the scroll position is reset to the top. Some could be worked around (like saving the scroll position and restoring it), but others could not (like iframes being reloaded). Now with moveBefore() all these moves can be done while preserving the element state, which can dramatically simplify the usage of the DOM in some cases.
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.
I'm thinking about better responsive UI designs that don't frustrate the user. Everyone hates cumulative layout shift as things load in and window resizes also require layout changes which are often implemented poorly.
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.
- 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
> move embedded iframe to lightbox for “full screen” and back
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.
This is a huge deal for SPA libraries which are, like it or not, fundamental to modern web development
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
Any layout system that modifies the DOM currently has to be careful not to touch certain elements (like focused text fields) if possible. Preserving state means you could treat these elements like any other, rebuilding the DOM out from underneath them as you please.
As a cybersecurity guy you should know that JavaScript is by far not the entire attack vector in the frontend landscape: the DOM, HTML, HTTP, CSS, browser implementations, etc are a most complete picture. JavaScript itself has evolved and is evolving from its basic roots.
Historically yes because we use unsafe languages just to parse HTML, CSS, HTTP but intrinsically those do not require unsafe things. For JIT the situation is different and without JIT performance would be problematic.
That said, the alternative to web apps is native platforms or other VMs which have the exact same problem except with less capital allocated towards mitigating it.
Probably something like dom-swapping the google login page or whatever. If you can keep arbitrary CSS transitions running, I could imagine doing a bunch of weird stuff where you don't know exactly what box you're typing in to.
If you can run arbitrary JS on the Google login page then you could simply intercept the form submission and steal the credentials... Am I missing something?
Is the ability to move elements preserving DOM state really the key to such attacks? Previously you could do the same but the iframe would reload - but if it's a small simple page, it could load very quickly, in which case it doesn't seem all that different to moving the iframe with its existing content.
I don't understand the need for this awkward API.
Ok, `otherParent.append(existingIframe)` reloads the iframe, but that's just a legacy behavior. Why not toggle the new behavior by calling `existingIframe.holdMyBeer()`? This way I could just continue using .prepend/.append/.before/.after et — which by the way support multiple elements at once, unlike moveBefore.
Ridiculous choice, but I'm not even surprised anymore.
Well, it's clear you didn't take the time to try. There are multiple threads on this and related topics, with inputs from all browser vendors.
This has been a high-priority standards request from framework and rendering library maintainers for many, many years. Chrome is not at all being ridiculous.
Next up — DOM parts and standardized signals, unified.
Then there's a direct line to built-in declarative reactive templating: https://github.com/WICG/webcomponents/issues/1069
You can do a lot better just checking if the template that/s rendering to a spot in the DOM is the same or different from the previous template. If it's the same, just update the bindings from the template, if it's different re-render the whole thing.
That's simpler and faster, but the one thing it leaves out is stateful reordering of lists. So you can have a specific re-ordering code path, which is simpler than a full VDOM, but if you want to preserve state like moveBefore() does, even that reordering gets pretty complicated because you can only preserve state for one contiguous range of nodes that you don't actually move - instead you move all the other nodes around them. moveBefore() just eliminates all that extra complexity.
There's also a couple of standards issues open for native reordering of siblings, like reorderChildren(). That would eliminate the re-ordering code completely.
vdom is necessary in react to abstract the view from the platform so it can be represented by react-dom and react-native[-x] bridges.
https://github.com/facebook/react/pull/32036
I'm not exactly sure what the developer experience of this would be, but I expect it would make Portals significantly more powerful and able to be hot-swapped into different containers without disrupting either their internal state or even things like loaded iFrames. I expect others will be experimenting heavily with this now that there's platform support.
https://github.com/facebook/react/issues/12247 (2018-2020) describes some of the use cases, with one partial solution being https://github.com/httptoolkit/react-reverse-portal - the conversation around caveats of these approaches would be entirely different now!
Iframes particularly have always been a pain point, as people often want to reparent them to move things around the DOM, but they always reload completely when you do so which causes all sorts of issues. This new API says it explicitly _doesn't_ reload iframes, so we'll be able to drop that caveat immediately (for supporting browsers, but hopefully Safari/FF will follow suit soon). Looks great!
You'll be able to reorder items in a list while preserving focus, without reloading iframes, and keeping audio and video playing.
We have a draft PR for support in Lit, and will try to ship that as soon as possible.
[1] https://github.com/mozilla/standards-positions/issues/1053
[2] https://bugzilla.mozilla.org/show_bug.cgi?id=1923880
> [stage 3] basically means "finished, pending editorial nit review---but since multiple implementations haven't happened yet, there's a reasonable chance that we'll discover something is broken, and need to fix the normative content
https://github.com/whatwg/meta/issues/336#issuecomment-24874...
No movement since its creation on October 10, 2024
The editor of the playground shows you the live DOM in its editor.
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.
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.
- 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.
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
That said, the alternative to web apps is native platforms or other VMs which have the exact same problem except with less capital allocated towards mitigating it.
Not really, at least on desktops: https://microsoftedge.github.io/edgevr/posts/Super-Duper-Sec...
https://developer.mozilla.org/en-US/docs/Web/Security/Attack...
What stops malicious JavaScript that would have used moveBefore() to just add key event listeners?