DOM state-preserving move

[noamr]

こんにちは TAG-さん!

I'm requesting a TAG review of DOM state-preserving move.

This is a feature that allows moving elements around the DOM without their state being reset as a result (e.g. iframes won't reload if moved in this manner)

• Explainer¹ (minimally containing user needs and example code): https://github.com/noamr/dom/blob/spm-explainer/moveBefore-explainer.md
• Specification URL: https://dom.spec.whatwg.org/
• Tests: https://wpt.fyi/results/dom/nodes/moveBefore/tentative
• User research: See the DOM issue (Atomic move operation for element reparenting & reordering whatwg/dom#1255). Several framework authors have participated in this discussion. Note that if frameworks adopt this, for many of their users will get this "for free".
• Security and Privacy self-review²: https://github.com/noamr/dom/blob/spm-explainer/moveBefore-explainer.md#self-review-questionnaire-security-and-privacy
• GitHub repo: https://github.com/whatwg/dom
• Primary contacts (and their relationship to the specification):
  • Dominic Farolino
  • Noam Rosenthal
• Organization(s)/project(s) driving the specification: Google
• Key pieces of existing multi-stakeholder (e.g. developers, implementers, civil society) support, review or discussion of this specification
• Key pieces of multi-implementer support:
  • See discussion at Atomic move operation for element reparenting & reordering whatwg/dom#1255. The proposal is now at stage 1 after a conversation with the stakeholders.
• External status/issue trackers for this specification (publicly visible, e.g. Chrome Status):
  https://chromestatus.com/feature/5135990159835136

Further details:

• I have reviewed the TAG's Web Platform Design Principles
• Relevant time constraints or deadlines: N/a
• The group where the work on this specification is currently being done: WHATWG
• The group where standardization of this work is intended to be done (if current group is a community group or other incubation venue): WHATWG
• Major unresolved issues with or opposition to this specification:
• This work is being funded by: Google

You should also know that...
A lot of work on this was already done in the WHATWG context, however there is still time until anything is shipped. So this is a good time to also get some input from TAG!
.

[jyasskin]

We consider it a mistake in the platform that element movement is handled by removing and then re-inserting nodes. We would prefer if this effort fixed the existing methods rather than adding new methods. Could the designers invest in some more thorough testing to see if this breaks a significant number of pages, rather than just assuming that it will? If changing all of the element-movement methods does break things, perhaps it would be compatible to change only the newer ones that are methods on ParentNode and ChildNode. In that case, we think the slight inconsistency between, e.g., append() and appendChild() is worth the more intuitive behavior on the newer method.

Thank you for bringing this to us. The WHATWG discussion seems like the right place to dig into the compatibility question, so we're happy to let them take it from here.

[jyasskin]

This review was discussed at TPAC 2024.