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.

Reply via email to