10 ms·
Chrome 133 Supports DOM State-Preserving Move with moveBefore()
- e40 2y agoAny idea how long before this makes it into Firefox?
- baybal2 2y ago[dead]
- AshleysBrain 2y agoMozilla 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 https://github.com/mozilla/standards-positions/issues/1053 [2] https://bugzilla.mozilla.org/show_bug.cgi?id=1923880 https://bugzilla.mozilla.org/show_bug.cgi?id=1923880
- AlexErrant 2y agoHere's Webkit's tracking issue https://bugs.webkit.org/show_bug.cgi?id=281223 https://bugs.webkit.org/show_bug.cgi?id=281223 No movement since its creation on October 10, 2024
- culi 2y agoIt's still an Emerging Web Specification. Seems a little premature to remove the feature flag tbh
- AlexErrant 2y agoIt'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-2487474159 https://github.com/whatwg/meta/issues/336#issuecomment-24874...
- sureIy 2y ago2028 at best
- egberts1 2y ago[flagged]
- quonn 2y agoExplain?
- ramses0 2y agoProbably 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/Attacks/Clickjacking https://developer.mozilla.org/en-US/docs/Web/Security/Attack...
- deleted 2y ago[deleted]
- AshleysBrain 2y agoIs 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.
- weird-eye-issue 2y agoIf 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?
- jy14898 2y ago> 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?
- wslh 2y ago
- salve-for-tears 2y agoWow! 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.
- Feathercrown 2y agoFlexbox allowed this within a flat list, but this is much more applicable
- arianvanp 2y agoreordering elements with CSS does not reorder them in the accessibility tree and thus is not really a good option in my opinion.
- paradox460 2y agoI've actually abused this feature in the past to satisfy bone headed layout decisions from on high that would have a dramatic negative effect on accessibility
- klinch 2y agoHonestly 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.
- jy14898 2y agohttps://reparent.jarhar.com/ https://reparent.jarhar.com/. Perhaps a good example is popping out a form when the user wants to navigate elsewhere to answer the questions.
- sublinear 2y agoI'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.
- curtisblaine 2y agoIf you don't do marketing / ads in your UI it's unexpectedly easy to make it easy to use. 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.
- spankalee 2y agoThis 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.
- jonkoops 2y agoAlso 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.
- qwertox 2y agoIf they could only fix the issue where resizing a text box almost grinds the entire OS to a halt, that would be nice.
- cetinsert 2y agohttps://dom.rt.ht/moveBefore https://dom.rt.ht/moveBefore is a playground with 2-way I-O sync! The editor of the playground shows you the live DOM in its editor.
- sinibida 2y agoUnrelated, 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?
- XCSme 2y agoNice, I was just adding https://github.com/react-grid-layout/react-grid-layout https://github.com/react-grid-layout/react-grid-layout to a dashboard, where you can drag/re-order charts. I assume this would make the implementation better.
- btown 2y agoFYI a quick search shows that React has already integrated this on its main branch! https://github.com/facebook/react/pull/32036 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 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 https://github.com/httptoolkit/react-reverse-portal - the conversation around caveats of these approaches would be entirely different now!
- pimterry 2y agoI'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!
- khana 2y ago[dead]
- notnullorvoid 2y agoThis 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.
- tengbretson 2y agoI haven't thought through how, but being able to move an element that has focus just has the feeling of something that could be exploited.
- sureIy 2y agoIn 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.
- spankalee 2y ago> 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.
- sureIy 2y agoYou didn't read my comment. I know what it's for, I don't agree with the API itself. Read my third paragraph.
- notnullorvoid 2y agoShipping it in its current state does seem premature. The spec still hasn't addressed a major concern from rendering library authors, which was that an explicit check to see if a node is connected is now required to branch between using moveBefore or insertBefore, since moveBefore throws if used to place a disconnected node.
- mary-ext 2y agoisn't it only on disconnected-disconnected case? it'd still require a separate path but it seems like something you can just check once (the parent)
- 2y ago
- wlib 2y agoThe 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.
- dimal 2y agoWhy would this eliminate the need for any VDOM algorithm? I could see how it would simplify VDOM diffing but not eliminate it altogether.
- spankalee 2y agoVDOM 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.
- theultdev 2y agothere's other reasons for the vdom though. 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.
- 2y ago
- etchalon 2y agoThis is one of those things you're shocked to find out didn't exist before.
- paradox460 2y agoThis is one of those little changes that just quietly drops, and winds up having tremendous impact. Like XMLHttpRequest back in the day
- recursivedoubts 2y agohtmx has supported moveBefore() since 2.0.3 in October of last year: https://github.com/bigskysoftware/htmx/blob/master/CHANGELOG.md#203---2024-10-03 https://github.com/bigskysoftware/htmx/blob/master/CHANGELOG... https://htmx.org/examples/move-before/ https://htmx.org/examples/move-before/ We initially asked for this new feature about two years ago and have worked with the Chrome team as they have implemented it. It is going to be a huge step forward for the web!
- dizhn 2y agoWhy am I getting rickrolled where it's supposed to show a demo of the feature on that page? :)
- recursivedoubts 2y agohave you tried restarting?
- dizhn 2y agoI tried singing along.
- recursivedoubts 2y agooh, good, glad you fixed it
- deleted 2y ago[deleted]
- CSSer 2y agoHeads up, this page has overflow issues.
- recursivedoubts 2y agohave you tried restarting?
- knowitnone 2y agoHave we seen any drops in Chrome marketshare?
- tommiegannert 2y agoWhy isn't it better to redefine insertBefore of an already inserted element to being state-preserving? If I want to kill state, I can do a remove first.
- Klaster_1 2y agoThis would break the WEB. JS DOM bindings are a backwards-compatible public API.
- tommiegannert 2y agoI reject that claim as-is. In what situations would it break? Standards evolve. Changes to cookies, iframes, newly required HTTP headers all "broke" the web. Not to mention Flash deprecation. But somehow we survived. Sure, this would theoretically be a backwards incompatible change. But if no one is using insertBefore without really meaning moveBefore, it's not a concern in practice.
- nitwit005 2y agoYou're both denying it would break, and saying it's okay for it to break, which are contradictory arguments.
- tommiegannert 2y agoPutting it your way, I'm saying it might break short-term, but long-term it would be fine.