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

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 milestones
Shipping on desktop 133

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 Status
https://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/CAP-uykDWtH4TSCj0d8hwvjT17kaM%3D3FjRD1Rs4FXi_kRTQTyVw%40mail.gmail.com.

Reply via email to