← back to v153 · interoperable-dispatch-timing-for-transitionrun-and-media-query-events

conformance · v153

v153 · interoperable-dispatch-timing-for-transitionrun-and-media-query-events — conformance probe

6 assertions drawn from the spec. Each is a single contract the spec text makes. Pass/fail reflects what this browser executed; blocked means the contract was not run because it needs user mediation, hardware, or another unavailable precondition. Open the page in Chrome stable / canary / Firefox / Safari to compare.

browser: spec: https://html.spec.whatwg.org/multipage/webappapis.html#event-loop-processing-model chromestatus: #6312504658624512 generated 2026-08-28T00:00:00Z by claude-opus-5-v153-build
0
pass
0
fail
0
blocked
6
total
id contract kind verdict detail
transitionrun-is-a-transition-event The event this change is about exists and carries the property it belongs to. spec ↗ script
media-query-lists-are-event-targets The other half of the change: a MediaQueryList dispatches change events, which is what puts a listener inside the rendering steps rather than in an ordinary task. spec ↗ script
transitionrun-precedes-transitionstart Both events are dispatched at the same step, and their order is fixed: run announces that a transition exists, start announces that its active interval has begun. A demo that measured the wrong one would report a delay that is really a delay value. spec ↗ script
animation-events-precede-animation-frame-callbacks Within one rendering iteration, animations are updated and their events sent before the animation frame callbacks run. Every frame count in these demos rests on this ordering, so it is asserted rather than assumed. spec ↗ script
a-media-query-listener-transition-runs-in-the-same-iteration The feature itself. A transition created inside a media query change listener must have its transitionrun dispatched later in that same rendering iteration, so no animation frame callback runs in between. A count above zero is the deferral Chrome 153 removes. spec ↗ script
a-scroll-listener-transition-runs-in-the-same-iteration The same requirement for the other event dispatched inside the rendering steps: a transition created in a scroll handler must not wait for the next iteration either. spec ↗ script