Meta: a list of side effects that would be impacted by state-preserving move about dom HOT 4 OPEN

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.

from dom.

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.

from dom.

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!

from dom.

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

from dom.