v153 · dispatch timing
A layout that animates on a breakpoint
The pattern where this matters: a media query listener that starts an animation, because a layout change should be a movement rather than a jump. Drag the width across the breakpoint and every crossing is timed.
Drag across the breakpoint
Every crossing is one measurement: the media query listener adds a class, and the page records how many animation frame callbacks passed before transitionrun arrived. Zero means the transition was announced in the same rendering iteration as the change that created it.
Every crossing
| # | direction | frames of delay | ms | verdict |
|---|---|---|---|---|
| No crossings yet. | ||||
Why a frame is worth arguing about
Alone, one frame is invisible. It stops being invisible when something is waiting on the event: a sequence that starts a second animation once the first has begun, a measurement taken on transitionrun, a test that asserts an animation started before advancing. Code written against Firefox or Safari and then run in Chrome would find the event a frame late — and code written the other way round would find it early.
That is the case for fixing it even though nothing about the API changes. The value is that the same code produces the same sequence everywhere, which is what makes a timing detail worth a release note.