demo · v139

Transition Property Lab

Three boxes, three different ways the transition property is mutated mid-flight. Watch the spec-compliant behaviour: the active animation runs to completion with its original timing, only new transitions pick up the changed values.

before-transition values

600ms

mid-flight switch to

2000ms
300ms
A · property unchanged
B · transition swapped (139+ keeps original timing)
C · old behaviour (would re-time)
played
switch at
switch value
B finishes at
C finishes at

what changed in Chrome 139

Before this fix, mutating the transition shorthand (or any transition-* longhand) on an element with a running transition could re-time the already-running animation. The CSS Transitions spec says it shouldn't — running transitions belong to the snapshot that started them. Chrome 139 brings the implementation in line with the spec: switching transition mid-flight, or even reverting it to initial, leaves the active animation untouched. Only the next change to an animatable property picks up the new timing.

snippet

/* Both rules apply at different times to the SAME element. */
.box {
  transition: transform 600ms ease-in;
  transform: translateX(0);
}
.box.move {
  transform: translateX(200px);  /* starts the 600ms ease-in */
}
.box.swapped-mid-flight {
  transition: transform 2000ms linear;  /* Chrome 139: this does NOT
                                           re-time the running animation.
                                           The translateX still completes
                                           in 600ms ease-in. The 2000ms
                                           linear only applies to the
                                           NEXT property change. */
}

see also