Chrome 133 Supports DOM State-Preserving Move with moveBefore()
23 comments
·February 5, 2025e40
Any idea how long before this makes it into Firefox?
AshleysBrain
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
salve-for-tears
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.
klinch
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.
AshleysBrain
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.
sublinear
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.
jy14898
https://reparent.jarhar.com/. Perhaps a good example is popping out a form when the user wants to navigate elsewhere to answer the questions.
jitl
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
panic
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.
spiderfarmer
If Chrome takes the lead it's probably all about moving ads around on the page.
egberts1
[flagged]
lhnz
If it weren't for JavaScript we'd still be downloading binaries and running them unsandboxed on our computers.
wslh
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.
incrudible
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.
quonn
Explain?
ramses0
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.
https://developer.mozilla.org/en-US/docs/Web/Security/Attack...
weird-eye-issue
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?
AshleysBrain
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.
jy14898
> I could imagine doing a bunch of weird stuff where you don't know exactly what box you're typing in to.
What stops malicious JavaScript that would have used moveBefore() to just add key event listeners?
null
This is going to be great for rendering libraries that do keyed loops and for some portal systems.
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.