- From: Stephen McGruer via GitHub <sysbot+gh@w3.org>
- Date: Thu, 12 Sep 2019 17:23:31 +0000
- To: public-css-archive@w3.org
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