Thanks for working on this, this is exciting!! On Thursday, November 14, 2024 at 9:17:13 PM UTC+1 Dominic Farolino wrote:
Contact emails...@chromium.org, nrosent...@chromium.org ExplainerExplainer <https://github.com/noamr/dom/blob/spm-explainer/moveBefore-explainer.md> Specificationhttps://github.com/whatwg/dom/pull/1307 What's preventing the PR from landing? Summary This feature adds a new DOM primitive (Node.prototype.moveBefore()) that allows moving connected elements around a DOM tree (same-Document), without resetting various pieces of element state. See this spec issue: https://github.com/whatwg/dom/issues/1255. The following state is ordinarily reset when an element moves in the DOM, but is preserved when the `moveBefore()` API is used: - Iframe documents (including unload events & document reloading) - Focus - Popovers - Modal dialogs - Fullscreen - CSS transitions & animations - Pointer events See https://github.com/whatwg/dom/issues/1270 for more. Blink componentBlink>DOM <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3EDOM> TAG reviewhttps://github.com/w3ctag/design-reviews/issues/976 TAG review status"Satisfied with concerns". TAG issue is resolved. Risks Interoperability and Compatibility None *Gecko*: Positive (https://github.com/mozilla/standards-positions/issues/ 1053) *WebKit*: Support (https://github.com/WebKit/standards-positions/issues/375) *Web developers*: Positive (https://github.com/whatwg/dom/issues/1255) See comments from *HTMX* <https://x.com/htmx_org/status/1790414137765294340> ( docs <https://htmx.org/examples/move-before/>) & *React* <https://gist.github.com/gaearon/ad9347f1f809b6fe5af15bb911bbaf6b#moving-and-reparenting-without-losing-state>, as well as *Angular* <https://github.com/whatwg/dom/issues/1255#issuecomment-2044930653>. *Other signals*: N/A WebView application risks Does this intent deprecate or change behavior of existing APIs, such that it has potentially high risk for Android WebView-based applications? None to speak of Debuggability None Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, ChromeOS, Android, and Android WebView)?Yes Is this feature fully tested by web-platform-tests <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md> ?Yes See https://wpt.fyi/results/dom/nodes/moveBefore/tentative? label=experimental&label=master&aligned Flag name on about://flagsAtomicMoveAPI Finch feature nameNone Non-finch justification This is a web platform API that should be made fully available in the milestone it is shipping with. The API is flagged, so we can kill it with Finch if needed. Requires code in //chrome?No MeasurementA WebDX use-counter named "MoveBeforeAPI" has been added <https://chromium-review.googlesource.com/c/chromium/src/+/6022264>, and is referenced in the IDL for `moveBefore()`. Adoption expectationThis feature will largely be used by framework authors when moving nodes around the DOM tree, and to a lesser extent, individual web developers specifically interested in this state preservation. Adoption planAdoption is relatively easy. Developers can start using `Node#moveBefore()` in place of `Node#insertBefore()`, while accounting for the extra scenarios that `moveBefore()` will throw an exception in. In the error case, developers can consider delegating to `insertBefore()` instead. Furthermore, adoption is made easy by the fact that all cases under which `moveBefore()` would throw are web-observable & testable by developers. Estimated milestonesShipping on desktop133 Anticipated spec changes Open questions about a feature may be a source of future web compat or interop issues. Please list open issues (e.g. links to known github issues in the project for the feature specification) whose resolution may introduce web compat/interop risk (e.g., changing to naming or structure of the API in a non-backward-compatible way). During the spec review process, we decided (along with other browsers) to not preserve DOM live Range state, which includes text selection (see this spec review thread <https://github.com/whatwg/dom/pull/1307#discussion_r1835433307>). The idea is that we'd revisit adding this if it becomes a serious developer want, but until then, the API will not preserve this state. We are hopeful that if we decide to add this preservation *later*, we can change the API to preserve this kind of state by default and still be web-compatible. However, the alternative would be to specify some options for the API to enable future kinds of preservation like Range/selection. Link to entry on the Chrome Platform Statushttps://chromestatus.com/ feature/5135990159835136?gate=5177450351558656 This intent message was generated by Chrome Platform Status <https://chromestatus.com/>. -- You received this message because you are subscribed to the Google Groups "blink-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscr...@chromium.org. To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/b2292167-712e-477d-833c-20c79f297875n%40chromium.org.