Meta: a list of side effects that would be impacted by state-preserving move

[noamr]

What is the issue with the DOM Standard?

In support of #1255, this issue tries to capture the exhaustive list of behaviors that would be impacted by an state-preserving atomic move operation (e.g. element.moveBefore(). It is based on references to insertion steps and removing steps.

Potentially skipped side effects

• IFrame/object/embed unload: See removing steps.
• Dialog close: see removing steps
• Popover close: see hide popover
• Text selection reset: set the selection range
• Exit fullscreen: see here
• Pointer event state reset: see here
• CSS transition restart: see here
• Hide nput/select picker: here
• img/source: this shouldn't count as a relevant mutation
• Cancel pointer lock: here
• Containment: keep last remembered size(see here)
• Selection API: don't reset (see here)

Potentially modified side effects

• Focus: see focusing steps. At the very least we need to check whether the new tree is inert.

Reflection

• Mutation observer: potentially reflect that there was a move
• Custom elements: see reactions. Perhaps add a movedCallback, that has a default to call disconnectedCallback and connectedCallback?

Noops

• Select element "selectedness": https://html.spec.whatwg.org/multipage/form-elements.html#the-select-element:html-element-insertion-steps

[WebReflection]

Mutation observer: potentially reflect that there was a move

It's already easy to fail behind MutationRecords order (added VS removed, which to check first? I check removed first and update the logic synchronously for libraries which goal is to reflect connected and disconnected behavior) so this would be awesome to tackle and I see only two ways to do so:

• both removed and added nodes lists refer to the same node with an extra moved boolean value (safe as it's undefined and considered always false to date, if ever even checked)
• movedNodes list enters the game with optionally a from and to references for the nodes

To be honest, this logic could be easily polyfilled too by checking the parentNode and isConnected properties of any removed node but if handled natively people would be surely happier ... the move operation is key to avoid tons of clean-up and events dispatching for something that maybe needs again, once reconnected, to bootstrap tons of stuff so it's not only the browser insertions/removals steps we all win, if less, it's a huge ecosystem of libraries that do a lot of work on disconnected and connected so I hope this MO related story will be as successful as the idea behind moving.

Custom elements ... Perhaps add a movedCallback, that has a default to call disconnectedCallback and connectedCallback?

That would be the least surprise and fully backward compatible so I am overly 👍 with the movedCallback idea and its defaulting to current behavior: disconnected + connected

This helps Web Components libraries authors to migrate while browsers adoption increase so it feels like a no-brainer to me and I hope it will be welcomed by others too.

[Kaiido]

I believe this would also affect being-rendered, whose exhaustive implications I am not sure.

• At least <object> and <embed>¹ would be affected.
• It might have effect on <img> element that allow auto-size, though I'm really not sure here.
• That might also affect <select> and <input> elements on which showPicker() has been called, keeping some pickers alive.

Footnotes

1. Though the specs for <embed> are a bit weird and ask the checks are made against the state at the first step of the event loop. But browsers do agree that moving it around in the DOM does trigger a reload, even if the move has been completed in the same EL iteration. ↩

[noamr]

I believe this would also affect being-rendered, whose exhaustive implications I am not sure.

• At least <object> and <embed>1 would be affected.
• It might have effect on <img> element that allow auto-size, though I'm really not sure here.
• That might also affect <select> and <input> elements on which showPicker() has been called, keeping some pickers alive.

Footnotes

1. Though the specs for <embed> are a bit weird and ask the checks are made against the state at the first step of the event loop. But browsers do agree that moving it around in the DOM does trigger a reload, even if the move has been completed in the same EL iteration. ↩

Thanls, added these!

[noamr]

I created a demo that tries to capture all these scenarios: https://state-preserving-atomic-move.glitch.me