Re: [web animations] Global playback rate

On 2015/09/05 4:06, Rachel Nabors wrote:
> Been seeing a need for a global playback rate for animations. Talking
> with accessibility experts about older users often needing slower
> animations makes me think this is something individual sites if not
> browsers themselves would like to offer user control over.

For the specific case of providing support for users who need a slower 
rate of animation I think the only thing needed is an extra level of 
abstraction added to the definition of times used by 
requestAnimationFrame etc.

I don't think it needs an additional API for setting the rate since I 
don't think you want sites to be able to override it, right? Or at 
least, you don't want sites that are slowing down or speeding up 
animations for other reasons to interfere with this setting, right? 
Maybe an API to get the scale factor would be useful though?

For other use cases, adding a global playback rate can lead to 
surprising side effects.

For example, suppose an author wants to pause animations on the page 
(perhaps while a modal dialog is showing). They set 
document.timeline.playbackRate = 0 and the animations freeze.

Then they notice that their hover transitions aren't working any more. 
Odd. What's more, all those things in their app that were keyed off 
transitionend events no longer run. In fact, suddenly the whole app is 
broken.

One of the motivations behind timing groups (which are spec'ed in level 
2[1]) is it lets you choose the subset of effects you want to 
synchronize and then do playback control on all of them at once.

However, another approach we could take is to reuse timelines for this. 
For example, you can already create a new DocumentTimeline and attach 
animations to it. If we added playbackRate to DocumentTimeline (or 
perhaps AnimationTimeline) you could divide animations into different 
timelines and control them separately. We'd then define 
requestAnimationFrame as using times from the "default document 
timeline"[2].

The tricky part is getting animations to track the right timelines.

For example, if you wanted to slow down all CSS animations and 
requestAnimationFrame animations without affecting transitions, you'd 
probably need a declarative way of getting transitions to track a 
different timeline. (We could say that transitions *always* track a 
different timeline but then I think that actually makes it more 
complicated. I'm happy to explore that, however, if need be.)

We already know we want to support animations that run on a different 
type of timeline (e.g. a timeline bound to scroll position or some touch 
gesture) so I think the next step is probably to work on the syntax and 
mechanics for specifying different timelines for animations.

(On a side note, I think that if we did that, it would make timing 
groups less important but not irrelevant. They would still provide 
sequencing behavior and would be useful way of expressing start-time 
synchronization between independent CSS animations.)

Best regards,

Brian

[1] 
http://w3c.github.io/web-animations/level-2/#grouping-and-synchronization
[2] http://w3c.github.io/web-animations/#default-document-timeline

Received on Monday, 7 September 2015 02:55:46 UTC