- From: Brian Birtles <bbirtles@mozilla.com>
- Date: Thu, 21 Feb 2013 10:36:25 +0900
- 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 diagram: https://dvcs.w3.org/hg/FXTF/raw-file/default/web-anim/img/time-calculations.svg 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 reversed. 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, Brian
Received on Thursday, 21 February 2013 01:36:57 UTC