[web-animations-1] Propose moving mutable timelines to web-animations-2

[stephenmcgruer]

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.

[birtles]

I agree this can be deferred.

(For what it's worth, one of the main motivations for allowing different DocumentTimelines with different origins was to be able to represent SVG animations whose timing is based on the load event for their outermost <svg> ancestor--but even that doesn't require changing the DocumentTimeline after construction as best I recall.)

[graouts]

I agree too, I don't see any pressing practical use for this feature.