I don't think you mentioned connectedMoveCallback everywhere connectedCallback is mentioned (and it's relevant).

• https://html.spec.whatwg.org/#custom-element-reactions

This was there already, seehttps://whatpr.org/html/10657/custom-elements.html#custom-element-reactions ("When it is moved"). Not sure what's missing?

• https://html.spec.whatwg.org/#element-definition (this one seems especially important)

Done

• It could do with some examples as well.

Added non-normative note and an example

Seems like#10828 should be addressed here too?

Seems like#10828 should be addressed here too?

I think it needs to be done separately; I've uploaded#10840.

Just noting#10954 (comment), which will require a small change to this PR if/when that one lands.

First off, I want to say thatmoveBefore is going to be a major win in terms of functionality — so, thanks so much for working on it!

That said, I wanted to raise a concern about the following part of the specification:

<p>To opt in to a state-preserving behavior while<spandata-x="concept-node-move-ext">moving</span>, the author can implement a "<codedata-x="">connectedMoveCallback</code>". The existence of this callback, even if empty, would  supercede the default behavior of calling "<codedata-x="">disconnectedCallback</code>" and "<codedata-x="">connectedCallback</code>". "<codedata-x="">connectedMoveCallback</code>" can also be an  appropriate place to execute logic that depends on the element's ancestors. For example:</p>

I find it confusing that the existence of aconnectedMoveCallback method on a custom element changes the behavior ofmoveBefore. I think it will lead to custom element authors needing to write emptyconnectedMoveCallback() {/* do nothing, just here to prevent disconnectedCallback */} methods — and that feels like an anti-pattern. It will also lead to integration uncertainty for folks trying to leveragemoveBefore.

By way of counter point, I don’tthink the presence of anadoptedCallback lifecycle method changes howadoptNode works, just like the presence ofconnectedMoveCallback won’t change how the currentinsertBefore works.

Is there any flexibility in the specification at this point to change that? Or, would it be possible to understand the rationale on this decision in a little more detail?

First off, I want to say thatmoveBefore is going to be a major win in terms of functionality — so, thanks so much for working on it!

That said, I wanted to raise a concern about the following part of the specification:

<p>To opt in to a state-preserving behavior while<spandata-x="concept-node-move-ext">moving</span>, the author can implement a "<codedata-x="">connectedMoveCallback</code>". The existence of this callback, even if empty, would  supercede the default behavior of calling "<codedata-x="">disconnectedCallback</code>" and "<codedata-x="">connectedCallback</code>". "<codedata-x="">connectedMoveCallback</code>" can also be an  appropriate place to execute logic that depends on the element's ancestors. For example:</p>

I find it confusing that the existence of aconnectedMoveCallback method on a custom element changes the behavior ofmoveBefore. I think it will lead to custom element authors needing to write emptyconnectedMoveCallback() {/* do nothing, just here to prevent disconnectedCallback */} methods — and that feels like an anti-pattern. It will also lead to integration uncertainty for folks trying to leveragemoveBefore.

This is by design. By adding this empty callback you signal that your component is capable of handling moves.

By way of counter point, I don’tthink the presence of anadoptedCallback lifecycle method changes howadoptNode works, just like the presence ofconnectedMoveCallback won’t change how the currentinsertBefore works.

I don't think this analogy is valid. The presence of the callback doesn't change how ’moveBefore’ works, only which custom element callbacks are called.

Is there any flexibility in the specification at this point to change that? Or, would it be possible to understand the rationale on this decision in a little more detail?

It's late at this point.

To explain the rationale:
This is to avoid breaking existing components that might assume that an element cannot be moved, as custom elements predate moving. For example, a custom element might check the tag name of Its parent in its ’connectedCallback’. Before moving this was guaranteed to not change until the next ’disconnectedCallback’, so by calling both callbacks by default we simulate the old behavior to ensure components that rely on it, and by providing the new callback the component can open out from that.

The presence of the callback doesn't change how ’moveBefore’ works, only which custom element callbacks are called.

@noamr — Thanks for the thoughtful response. I get your point from a “don’t break the web perspective”, but I am struggling to understand the mental model related todisconnectedCallback andmoveBefore.

I had previously thought that part of thepoint of usingmoveBefore was toprevent disconnection. I.e., I usemoveBefore on some set of elements to ensure that theydon’t disconnect — why is it the case that usingmoveBefore doesn’t guarantee thatdisconnectedCallback is skipped? Perhaps I just need to fix my mental model to think about these lifecycle methods asmaybeDisconnectedCallback andmaybeConnectedCallback.

Either way, I’ll just bakeconnectedMoveCallback into a base element and I’m excited to see this stuff landing ❤️

The presence of the callback doesn't change how ’moveBefore’ works, only which custom element callbacks are called.

@noamr — Thanks for the thoughtful response. I get your point from a “don’t break the web perspective”, but I am struggling to understand the mental model related todisconnectedCallback andmoveBefore.

It also fires the connectedCallback straight after. The mental model is that if your existing component is not prepared for a move, it should fall back to disconnecting and reconnecting, like a "restart" to make sure it didn't go into some funky state.

I had previously thought that part of thepoint of usingmoveBefore was toprevent disconnection. I.e., I usemoveBefore on some set of elements to ensure that theydon’t disconnect — why is it the case that usingmoveBefore doesn’t guarantee thatdisconnectedCallback is skipped? Perhaps I just need to fix my mental model to think about these lifecycle methods asmaybeDisconnectedCallback andmaybeConnectedCallback.

Either way, I’ll just bakeconnectedMoveCallback into a base element and I’m excited to see this stuff landing ❤️

In case it helps, a possible mental model might be that it disconnects and reconnects the vast majority of elements (e.g.<p>,<div>,<strong>, custom elements by default, ...). But for certain special elements it performs a move (e.g.<img>,<iframe>,<select>,<audio>,<video>, certain custom elements, ...).

@domenic — That is actually super helpful! Makesmuch more sense to me that this works the way it does 🤘

@domenic — That is actually super helpful! Makesmuch more sense to me that this works the way it does 🤘

Thanks for asking for clarifications, I will make sure this is reflected in documentation.