Platform/Layout/Extended Timelines

Summary: Following is a rough sketch of how the Web Animations API could be adapted to support scrubbing animations based on scroll position and (less critical) touch events.

Background reading: Web Animations spec, in particular the timeline and player concepts. Some additional background about players is on this blog. I (Brian) am not crazy about the idea but I think it's workable.

API

[Constructor ((Window or Element) scrollSource, Orientation orientation)
interface ScrollTimeline : AnimationTimeline {
  attribute Orientation orientation;
};

// Is there an existing enum somewhere we can use for this?
enum Orientation { "vertical", "horizontal" };

The currentTime of a ScrollTimeline would be basically scrollTop/scrollY or scrollLeft/scrollX (with the exception that it would track smooth scrolling even though this isn't reported to the DOM, see bug 1010538). We could probably add scaling parameters here too, possibly based on scrollHeight/scrollMaxY etc.

The playbackRate of an AnimationPlayer provides the mapping from scroll units to time units.

interface AnimationPlayer : EventTarget {
   ...
   // Can be "auto" or a double
   (double or DOMString) playbackRate;
}

Example usage

// Makes the character spin 180deg as you scroll the div
var timeline = new ScrollTimeline(div, "vertical");
timeline.play(new Animation(character, { transform: "rotate(180deg)" }, 100));

Note that this current approach doesn't require a subclass of AnimationPlayer like I thought it might.

Also note that by using a regular player you can have several animations tracking the same scroll container and then call pause(), reverse(), finish(), and update playbackRate etc. to take them out of the flow or change the way they track the scroll position. Setting startTime or adjusting the animation's delay can also allow offsetting them.

Implementation issues

If smooth scrolling is performed on the compositor, but the animation being scrubbed can only be run on the main thread we'll probably need to run the smooth scrolling interpolation code on the main thread as well.

Update: Apparently the main thread still gets scroll events (lagging behind a bit) and we can drive the animation from there.

Implementation strategy

We could probably start with a very limited subset that:

• Is only enabled when OMTC and OMTA is enabled (no longer needed if we can drive main-thread animations via scroll events although it might be useful in terms of initially limiting the scope)
• Throws an exception when trying to associate animation content that targets anything other than 'transform' with a ScrollTimeline (also, no longer needed?)
• Simply fails to animate if preserve-3d etc. is set (anything that prevents us from doing OMTA but which could change from sample to sample) (As with the first point, no longer strictly needed)
• Is only enabled for Gaia apps

Then we could gradually work at removing those restrictions in parallel with standardizing it.

Touch-based scrubbing

I'm not sure what the exact parameters would be here, but presumably we could use a similar approach.

Declarative syntax

If the API approach works, we could later map it to CSS using an animation-timeline property. Tab previously had some ideas around this.

Other timelines

I think there is potential for addressing some other use cases by providing further timelines:

• FrameBasedTimeline - Some sorts of animations have fixed frames and they don't want to drop frames even if it leads to jank (e.g. [1]). This timeline would only increment the currentTime by a fixed amount on each sample (probably with some tolerance parameters).
• WorkerTimeline - Only really useful for setting up animations consisting entirely of javascript callbacks (see "custom effects" in the spec) but that could still be useful e.g. for animating a CanvasProxy, WebGL (bug 709490) etc. using the same animation API