W3C home > Mailing lists > Public > www-style@w3.org > February 2013

Re: timing functions in reversed animations

From: Brian Birtles <bbirtles@mozilla.com>
Date: Thu, 21 Feb 2013 10:36:25 +0900
Message-ID: <51257A19.8000300@mozilla.com>
To: www-style@w3.org
(2013/02/21 3:09), Dean Jackson wrote:
> This was discussed at the call today: http://lists.w3.org/Archives/Public/www-style/2011Mar/0744.html
> What was intended in the original spec proposal, and what WebKit implements is actually pretty simple.
> For any animation/transition, you calculate a "progress" based on (currentTime - startTime) / duration,
> where startTime is the time the current iteration began, producing a value between 0 and 1. You use this
> value directly when animating forwards. When you are in the reverse cycle, you use (1 - progress). This
> value is then input into the style calculation.
> Effectively this means a reverse phase is a mirror image of the forwards phase, as Simon said.

That sounds like what we've specified for Web Animations as per this 


i.e. the reversing (playback rate) is applied, then the direction, then 
the timing function.

The timing function is applied to a progress fraction in the way you 
mention (currently specified in 13.6 Calculating the transformed time, 
although section numbers will probably change a lot in the next few days).

> I think everything w.r.t keyframes becomes pretty obvious now, since you use the evaluated progress
> to calculate where you are in the set of keyframes and forwards/reverse really makes no difference. You
> never need to "flip" the timing function - it's the input progress that runs backwards in reverse.

The operation of timing functions specified at keyframe-level operates 
as you suggest. That is, it takes place after the progress has been 

If CSS wants to use a different approach for reversing then we would 
probably just define the mapping from CSS to Web Animations such that 
reversing generates a separate 'reverse' animation.

Best regards,

Received on Thursday, 21 February 2013 01:36:57 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:08:26 UTC