[csswg-drafts] [web-animations-1] Propose moving mutable timelines to web-animations-2 (#4299)

stephenmcgruer has just created a new issue for https://github.com/w3c/csswg-drafts:

== [web-animations-1] Propose moving mutable timelines to web-animations-2 ==
This is a proposal to move the [mutability of timelines](https://drafts.csswg.org/web-animations-1/#dom-animation-timeline) on the Animation interface to the level 2 version of the spec. If adopted, the timeline attribute of the [Animation interface](https://drafts.csswg.org/web-animations-1/#animation) 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 https://github.com/w3c/csswg-drafts/issues/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](https://wpt.fyi/results/web-animations/interfaces/Animation/idlharness.window.html?label=master&label=experimental&aligned), 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.


Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/4299 using your GitHub account

Received on Thursday, 12 September 2019 17:23:33 UTC