CSS Animation Worklet API

[majido]

Request for Mozilla Position on an Emerging Web Specification

• Specification Title: CSS Animation Worklet API
• Specification or proposal URL: https://drafts.css-houdini.org/css-animationworklet/
• Caniuse.com URL (optional):
• Bugzilla URL (optional):
• Mozillians who can provide input (optional): @birtles, @heycam, @dbaron

Other information

This is specification that is being developed as part of CSSWG's Houdini Task Force. It is new Houdini style primitive that provides extensibility in web animations and enables high performance scripted animations on the web.

The specification has been incubating in Houdini/WICG since October 2016 and has gone through multiple major redesigns in the working group to ensure compatibility with existing web APIs and browser engines. The current design is implemented in Blink behind a runtime feature flag.

Explainer: https://github.com/w3c/css-houdini-drafts/blob/master/css-animationworklet/README.md Tests: https://github.com/web-platform-tests/wpt/tree/master/animation-worklet

[bzbarsky]

So first of all, I started trying to read the spec, realized that all sorts of parts of it are nonsense (e.g. https://github.com/w3c/css-houdini-drafts/issues/906 and https://github.com/w3c/css-houdini-drafts/issues/908), checked the Blink code for that second thing and realized that their code looks nothing like what the spec is maybe trying to say, and gave up on trying to review this thing.

Second, this has the same design as other worklet specs in being very ES-bound and it not being clear how to integrate it effectively with WebAssembly. @lukewagner might have some thoughts on that.

[birtles]

This is my last official day with Mozilla so my point of view is less relevant, but two points worth mentioning:

• Google have been very responsive to feedback on this and have changed the shape of this spec significantly as a result. This is much appreciated.

• My personal point of view is that it's not yet entirely clear that both the complexity of this feature, and the risk that it constrains future architectural changes by being fairly low-level, is sufficiently justified by use cases that are not and never will be possible with scroll-linked animations.

  My preference would be to ship scroll-linked animations (including their CSS syntax) and demonstrate that it can never meet a number of important use cases, before committing to this. (I suspect it will prove to be a necessary piece but I'd rather be a bit more confident, and I'd rather we tackle the more declarative approach first if possible.)

[smfr]

I concur with the previous comment. WebKit does scrolling in MobileSafari, and we're not willing to run client JS in a worklet in that process, so scroll-linked effects with worklets would not be possible for us to implement with our current architecture, and ScrollTimeline would be hard.

[majido]

@bzbarsky Thanks for feedback on the spec so far. I have responded to some of the issues that were raised on the intent thread. Basically difference between implementation and spec is mostly due to recent resolution in WG. We plan to update the specification to reflect those. And more generally we are committed to improving the specificcation before we ship. I will reach out once those are done.

@smfr To clarify Animation Worklet does not require running on any particular thread/process (though its predecessor Compositor Worker did). It is definitely acceptable to run it in on main rendering thread but the worklet semantic enables the engines to have the worklet run on a dedicated thread as a performance/smoothness optimization. This is the same semantic as Paint Worklet.

For example in Blink we run Animation Worklet off-main thread only for our fast path animations (e.g., opacity, transform) and "on" main thread for other animations mainly because we have existing machinery to animate those off-thread. Other engines may optimize this differently. Even then, in Blink it is not on the same thread as scrolling/compositing so it cannot block that thread!

As for scroll-linked effects and ScrollTimeline in particular, depending on the engines scrolling/animation architectures, I believe there will be many animations that cannot be in sync with fast-path scrolling even with the declarative approach. For example in the current Blink architecture layout inducing properties such as width, font-size can only run on the main thread. So in Blink, any scroll-linked animation of width cannot be in sync with actual scrolling regardless of whether it is driving a regular Web Animation or an Animation Worklet. I imagine it will be similar in MobileSafari.

Note also that Animation Worklet is orthogonal to Scroll Timeline. They are designed to work well together but don't require each other. We like Scroll Timeline and think we should implement that as well (we have a prototype of it in Blink). It should be promoted as the tool for many common scroll-linked effects. Animation Worklet should be used for usecases where the animation cannot be expressed with current animation APIs regardless of whether it is a time-based on scroll-linked animation.

[SebastianZ]

I have just created https://bugzil.la/1582695 as a meta-bug for implementing this feature before I found this issue.

So it looks as the current position of Mozilla is that the spec. is not ready for implementation and that at leas the scroll-related use cases for this might already be covered by the Scroll-linked Animations specification.

Sebastian