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
