This is very exciting, and I'm eager for this capability to ship, but I'm also worried that we're only doing one of the many append/insert API variants here. Is this the start of a larger package of additions? Or the only planned version?
Best, Alex On Wednesday, November 20, 2024 at 7:38:04 AM UTC-8 Yoav Weiss wrote: > 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/d4ad2c0c-05a4-4d40-8d91-aebc043d4489n%40chromium.org.
