-
Notifications
You must be signed in to change notification settings - Fork 295
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Introduce moveBefore()
state-preserving atomic move API
#1307
base: main
Are you sure you want to change the base?
Conversation
moveBefore()\
state-preserving atomic move APImoveBefore()
state-preserving atomic move API
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think the mutation record needs some more design work. I would expect it to capture the information of a remove and an insert at the same time. Perhaps it needs to be a new object, though we could further overload the existing MutationRecord
as well I guess. At least I think you need:
- old target
- target
- moved node (I'm not sure you can ever move multiple at this point, but maybe we should allow for it in the mutation record design?)
- old previous sibling
- old next sibling
- previous sibling
- next sibling
Would be good to know what @smaug---- thinks and maybe @ajklein even wants to chime in.
dom.bs
Outdated
<li><p>Let <var>return node</var> be the result of <a>pre-inserting</a> <var>node</var> into | ||
<a>this</a> before <var>child</var>.</p></li> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think it would be cleaner if we introduced "move" instead of overloading "insert", though I'm willing to be convinced. At least I always viewed this as introducing "move" as the third primitive following "insert" and "remove".
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah I think initially I saw it as a separate primitive too, but the more I looked at it, the more the difference between the two seemed really subtle. It mostly has to do with MutationObservers (and half of the relevant logic here is tucked away in the "remove" primitive) and not running the post-connection steps. So I feel like we'd end up with a near line-by-line copy of "insert", modulo one or two small differences. I'll take another look to see if my intuition is accurate, but I do kinda suspect this is where we'd end up.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It'd be good to have more details. Because you can't move a DocumentFragment
so a vast number of checks don't apply. Adopt won't ever run.
There might be a number of range and shadow tree checks that end we end up duplicating, but perhaps that calls for abstracting those instead. At least to me a state flag seems rather unappealing.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's possible there is enough from "insert" that we'd omit in "move", to make it creation worth it, sure.
At least to me a state flag seems rather unappealing.
With a separate "move" primitive and the decision to throw when we can't "move", we could get rid of the state variable that's currently in "insert" (i.e., <var>statePreservingAtomicMoveInProgress</var>
). But the state bool on Document
is what other specifications will refer to in their removal steps to react to a move appropriately, so I'm not sure we can get rid of that one.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hmm, wouldn't we give other specifications "move steps"?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I thought about this a bit more. I think we're happy to create a new "move" primitive algorithm following the "insert" and "remove" algorithms. As you mentioned, it will be a simpler algorithm than "insert" since we'll avoid the DocumentFragment
stuff — oh and also the post-connection stuff, among maybe more things.
There's still the discussion around introducing either (a) new "move" steps/hook that other specs provide to react to moves, vs (b) a Document-scoped boolean that the new "move" algorithm sets, for existing insertion/removal steps to use, to not reset certain state inside those steps.
Option (b) is the direction of the current PR, which we think makes sense after implementing this in Chromium. I think this is because so far we've found no behavior that we specifically want to do during a move that isn't done by insertion/removal — so any "move steps" we provided would just be empty. Does that make sense?
Now, I think the real question here is whether we want to:
- Keep running the insertion/removal steps during a "move" operation, and just pepper
if during atomic move is true, don't run some of these substeps!
wherever state would ordinarily be reset- Cancel out the iframe removal steps
- Cancel img relevant mutations, to avoid re-firing load events
- Simply not run insertion/removal hooks at all during a move. This is only feasible if we determine that there are absolutely no steps in any spec's existing insertion/removal hooks that need to run during a move. We'll have to do an audit to determine this, which I'm starting now.
So the way I see it, those are probably our options, as opposed to creating new move steps which I think from our findings so far, would be unused. (We'll course-correct if this finding changes).
Shouldn't the target node be all the time the same, it is just the siblings which change. If this is really just remove and add back elsewhere, we could just reuse the existing childList MutationRecords, one for remove, one for adding node back, and possibly just add a flag to MutationRecord that it was about move. (movedNodes is a bit confusing, since it seems to depend on the connectedness of the relevant nodes and it is apparently empty for the removal part. And it is unclear to me why we need the connectedness check. This is about basic DOM tree operations, and I'd assume those to work the same way whether or not the node is connected) |
Creating two separate mutation records that a consumer would have to merge to (fully) understand it's a move seems suboptimal? I agree that it should probably work for disconnected nodes as well, but I don't think we want to support a case where the shadow-including root changes. |
It's been a long time since I've thought about this stuff, but I'm inclined to agree with @smaug---- that creating a new type of |
This CL makes moveBefore() match the spec PR [1], with regard to the agreed-upon error-throwing behavior for all pre-moving validity and hierarchy conditions. This means throwing an exception for: - Disconnected parent destination or move target - Cross-document Nodes - Destination parent that is not an Element node - Move target that is not an Element or character data [1]: whatwg/dom#1307 [email protected] Bug: 40150299 Change-Id: Iaf5243fb2762e21ede068a222600bd158859fe92
This CL makes moveBefore() match the spec PR [1], with regard to the agreed-upon error-throwing behavior for all pre-moving validity and hierarchy conditions. This means throwing an exception for: - Disconnected parent destination or move target - Cross-document Nodes - Destination parent that is not an Element node - Move target that is not an Element or character data [1]: whatwg/dom#1307 [email protected] Bug: 40150299 Change-Id: Iaf5243fb2762e21ede068a222600bd158859fe92 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5935350 Reviewed-by: Noam Rosenthal <[email protected]> Commit-Queue: Dominic Farolino <[email protected]> Cr-Commit-Position: refs/heads/main@{#1369303}
This PR introduces a new DOM API on the
Node
interface:moveBefore()
. It mirrorsinsertBefore()
in shape, but defers to a new DOM manipulation primitive that this PR adds in service of this new API: the "move" primitive. The move primitive contains some of the DOM tree bookkeeping steps from the remove primitive, as well as the insert primitive, and does three more interesting things:connectedMoveCallback()
The power of the move primitive comes from the fact that the algorithm does not defer to the traditional insert and removal primitives, and therefore does not invoke the removing steps and insertion steps. This allows most state to be preserved by default (i.e., we don't tear down iframes, or close dialogs). Sometimes, the insertion/removing step overrides in other specifications have steps that do need to be performed during a move anyways. These specifications are expected to override the moving steps hook and perform the necessary work accordingly. See whatwg/html#10657 for HTML.
Remaining tasks (some will be PRs in other standards):
focusin
event semantics[ ] Preserve text-selection. See set the selection range. Edit: Nothing needs to be done here. Selection metadata (i.e.,selectionStart
and kin) is preserved by default in browsers, consistent with HTML (no action is taken on removal). The UI behavior of the selection not being highlighted is a side-effect of the element losing focusselectionchange
event: We've decided to allowselectionchange
event to still fire, since it is queued in a task. No changes for this part are required.Node.prototype.moveBefore
) WebKit/standards-positions#375Node.prototype.moveBefore
) mozilla/standards-positions#1053(See WHATWG Working Mode: Changes for more details.)
Preview | Diff