Changing a cell's z (toFront/toBack) cancels in-flight CSS transitions on that cell

[ian-appmixer]

Description

Reordering a cell with toFront() / toBack() (or any z change) re-sorts the cell views by re-inserting the cell's SVG node. If a CSS transition on that cell is triggered in the same tick — e.g. toggling a state class that animates fill/stroke — the transition does not play: the property snaps to its final value instead of easing.

That makes two natural things hard to do at once: animate a state change and raise the affected cell above its neighbours.

Version: @joint/core 4.2.x

Minimal reproduction

Two overlapping elements (so a z change actually reorders the DOM), with a CSS transition on the body keyed off a class:

.joint-cell [joint-selector="body"] { transition: fill .3s ease; }
.joint-cell.highlight [joint-selector="body"] { fill: tomato; }

paper.on('element:pointerclick', (view) => {
  view.el.classList.add('highlight'); // should animate fill → tomato …
  view.model.toFront();               // … but re-sorting re-inserts the node, so it snaps
});

Expected: the body fill eases to tomato over .3s.
Actual: it jumps instantly. (Remove the toFront() line and it animates as expected.)

Workaround

Defer the z / toFront() change until after the transition has finished (e.g. a timeout matching the transition duration), so the re-insert happens when nothing is animating — then both the ease and the reorder occur.

Question

Is this avoidable within JointJS (e.g. reordering without re-inserting the node, or skipping a no-op re-sort), or is it inherent to SVG reordering? Either way a note in the docs would help.

[ian-appmixer]

Alternative workaround, if the deferred reorder is noticeable as a second, after-the-fact change: reorder first, then start the transition a beat later — so the stacking change stays immediate.

paper.on('element:pointerclick', (view) => {
  view.model.toFront();                 // re-sort now, still at the old style
  requestAnimationFrame(() => requestAnimationFrame(() => {
    view.el.classList.add('highlight'); // then transition — it eases from the old style
  }));
});

Catch: the re-insert drops the node's transition "from" baseline, so reordering and changing the style in the same frame still snaps. The re-inserted node has to render once at the old style before the change — hence the beat (the two requestAnimationFrames above, or a forced reflow) between the reorder and the transition.