[css-transitions-1] Clarify/confirm behavior when reparenting a transitioning element

[stephenmcgruer]

What steps will reproduce the problem?
(1) Navigate to https://output.jsbin.com/celuzow/quiet
(2) Click start transition.
(3) Click reparent element during the transition.

In Chrome, Firefox and Safari, the transition is immediately finished. In Edge, the transition animation is continued after the element is reparented.

From the Chrome side we believe the immediate-finish behavior is correct; I just want to make sure that the spec backs this view, and add a WPT test if one doesn't already exist. One argument may be that it is covered by https://drafts.csswg.org/css-transitions/#starting :

If an element is no longer in the document, implementations must cancel any running transitions on it and remove transitions on it from the completed transitions.

Technically reparenting requires removing the element from its previous parent before setting the new parent. Whether that constitutes being 'no longer in the document' I'm not sure.

[tabatkins]

The precise nature of the "slow transition" behavior isn't super-specified (tho Web Animations does some nice work in reifying the transition into an explicit Animation object), but I agree with you that Chrome/Firefox/Safari's behavior is the desirable one.

Basically, moving an element in the tree should clear all style-related information about it; as far as CSS is concerned, the old element simply evaporated into thin air and a brand new element appeared somewhere else. Thus, just as transitions are canceled when the property they're associated with gets changed again, transitions should simply be dropped when their associated element disappears. This is the same behavior you'd get from flickering it to display:none and back.

Whether a move is technically a "remove, then insert" (I think it is for other purposes?), it should be treated the same for transition-canceling purposes.

[birtles]

I agree with that interpretation but would it help to explicitly call that out somehow? If so, I'm not sure if that should happen by referencing so generic CSS machinery, or by just extending that sentence with some appropriate DOM vocabulary to the effect of, "If an element is no longer in the document or is assigned a different parent node...".

Once we have that, we can more easily add a WPT for this.

[Loirooriol]

If an element is no longer in the document or is assigned a different parent node...

Firefox and Chromium finish the transition even if the parent node is the same, and even if the node ends up at the same place (e.g. if you use appendChild but the node is already the last child).

I guess the relevant step is https://dom.spec.whatwg.org/#concept-node-adopt

2. If node’s parent is not null, remove node from its parent.

So the element is temporarily 'no longer in the document', even if it's inserted back into the document immediately after.

[stephenmcgruer]

Given that that wording exists in the DOM spec, I propose I add a css-transition/ WPT test (or tests) to ensure this behavior and we don't adjust the css-transitions-1 spec. I am open to opposing opinions :).