Chrome 133 Supports DOM State-Preserving Move with moveBefore()

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!

This will need refactoring before being enabled, and possibly might not be enabled at all because it would introduce a perf regression do to the necessary checks to branch between moveBefore or insertBefore.

This was brought up multiple times to the html spec authors, but no changes were made.

Heads up, this page has overflow issues.

Why am I getting rickrolled where it's supposed to show a demo of the feature on that page? :)

DOM Parts + Signals will be an absolute game changer for the web platform.

Then there's a direct line to built-in declarative reactive templating: https://github.com/WICG/webcomponents/issues/1069

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.

Why would this eliminate the need for any VDOM algorithm? I could see how it would simplify VDOM diffing but not eliminate it altogether.

Signal based libraries already don't need VDOM. It's possible that it'll allow faster reordering of elements that are already connected, but the added checks needed to see if an element is connected (need to use insertBefore if not connected) might also cause overall perf regression. The main thing is that it allows elements to be moved without triggering disconnect/connect.

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.

Flexbox allowed this within a flat list, but this is much more applicable

Mozilla have a positive view of the API [1], but it doesn't look like development has started [2].

[1] https://github.com/mozilla/standards-positions/issues/1053

[2] https://bugzilla.mozilla.org/show_bug.cgi?id=1923880

Here's Webkit's tracking issue https://bugs.webkit.org/show_bug.cgi?id=281223

No movement since its creation on October 10, 2024

It's still an Emerging Web Specification. Seems a little premature to remove the feature flag tbh

2028 at best

Unrelated, but this is my first time knowing about RTCode.io, and it looks amazing! But it seems that there's not much information/documentations that I could search.

Would you mind sharing some if you are experienced with it?

This would break the WEB. JS DOM bindings are a backwards-compatible public API.

> 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.

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

https://github.com/whatwg/meta/issues/336#issuecomment-24874...

There are plenty of reasons to be upset with chrome.

This is not one of them.

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.

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.

This is exciting

- 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

I have a little test that has a DateStamp of 2011 that suggests I needed this functionality some time ago.

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.

This functionality, when it is widely available, solves the slowest and hardest part of the magic that DOM diffing libraries like morphdom provide.

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.

https://reparent.jarhar.com/. Perhaps a good example is popping out a form when the user wants to navigate elsewhere to answer the questions.

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

I assume this is big news for htmx (and the likes)?

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.

If Chrome takes the lead it's probably all about moving ads around on the page.