We need this in Handle transition frame as well. Iterate through all the elements and check if any of them is fragmented. If so, skip.

The idea being that we ignored fragmented elements when looking for elements with a view-transition-name. But if an element became fragmented during the animation, we skip the transition.

I didn't see any of this in the resolution. The resolution was that fragmented elements are ignored, not that they cancel the transition. Am I missing a conversation? Do we need to deal with this at all after elements were captured?

This was part of option 1 which we were asking the group to resolve on:

"When constraints are broken, transitions skip to the end (#7882).
Sub-option: Is the constraint broken if an element fragments, or if an element can fragment?"

We have a similar pattern with elements having a box. Safely ignore an element which has a view-transition-name but doesn't generate a box: https://drafts.csswg.org/css-view-transitions-1/#capture-old-state-algorithm:~:text=for%20element.-,If%20transitionName%20is%20none%2C%20or%20element%20is%20not%20rendered%2C%20then%20continue.,-If%20any%20of

But because elements in the new DOM are live, this state can change for them while the transition is running. We treat them as developer errors and abort the transition: https://drafts.csswg.org/css-view-transitions-1/#update-pseudo-element-styles:~:text=If%20any%20flat%20tree%20ancestor%20of%20capturedElement%E2%80%99s%20new%20element%20skips%20its%20contents%2C%20or%20capturedElement%E2%80%99s%20new%20element%20is%20not%20rendered%2C%20then%20return%20failure.

So the logic is that if a DOM element was not fragmented when the transition started but becomes fragmented during the animation, then the safest way to handle it is to abort the transition.

Done

Sorry for the confusion but now that dug through the spec to answer your question, step 8.8.3.1 here seems like a better spot for this. We already check all the other per element constraints which abort the transition here.

Done