This is a proposal to move the mutability of timelines on the Animation interface to the level 2 version of the spec. If adopted, the timeline attribute of the Animation interface would be marked readonly in the level 1 spec.
Motivation
This proposal is motivated on two fronts: firstly, the utility of mutable timelines in web-animations-1, and secondly the difficulty of implementing them in Chromium (our implementation presumes a lot about the timeline not changing). The goal is to clear the path for all web browsers to ship web-animations-1 in an interoperable way.
In #3759 I requested input on the use case for timeline being writable. The conversation was focused on ScrollTimeline, but no other usecases for mutable timelines were presented. Briefly scanning the spec, I did not find mutable timelines required for any of the use-cases.
To be clear; I have no disagreement with mutable timelines, they just don't have clear utility to me in web-animations-1 today.
Based on the WPT tests, I believe timelines are currently mutable in Firefox and Safari, and not mutable in Chromium.
Implications
There are three transitions possible with the web-animations-1 spec today:
- moving from one DocumentTimeline to another,
- moving from a DocumentTimeline to null,
- moving from null to a DocumentTimeline.
The first of these does not seem to have much use. The most one can do with a different DocumentTimeline is apply an offset, which could also be done by modifying the Animation's timing.
Going to/from null does have an effect - it makes the current time null/non-null, which then essentially makes the Animation 'happen' or not. However it is unclear to me if there is a situation where a web developer would prefer this over pausing, finishing, or cancelling their animation (and if there is such a situation, it feels like that highlights a hole in our API surface?). I would welcome input if someone believes there is an important use-case here.
This is a proposal to move the mutability of timelines on the Animation interface to the level 2 version of the spec. If adopted, the timeline attribute of the Animation interface would be marked readonly in the level 1 spec.
Motivation
This proposal is motivated on two fronts: firstly, the utility of mutable timelines in web-animations-1, and secondly the difficulty of implementing them in Chromium (our implementation presumes a lot about the timeline not changing). The goal is to clear the path for all web browsers to ship web-animations-1 in an interoperable way.
In #3759 I requested input on the use case for
timelinebeing writable. The conversation was focused on ScrollTimeline, but no other usecases for mutable timelines were presented. Briefly scanning the spec, I did not find mutable timelines required for any of the use-cases.To be clear; I have no disagreement with mutable timelines, they just don't have clear utility to me in web-animations-1 today.
Based on the WPT tests, I believe timelines are currently mutable in Firefox and Safari, and not mutable in Chromium.
Implications
There are three transitions possible with the web-animations-1 spec today:
The first of these does not seem to have much use. The most one can do with a different DocumentTimeline is apply an offset, which could also be done by modifying the Animation's timing.
Going to/from null does have an effect - it makes the current time null/non-null, which then essentially makes the Animation 'happen' or not. However it is unclear to me if there is a situation where a web developer would prefer this over pausing, finishing, or cancelling their animation (and if there is such a situation, it feels like that highlights a hole in our API surface?). I would welcome input if someone believes there is an important use-case here.