- From: L. David Baron <dbaron@dbaron.org>
- Date: Tue, 3 Apr 2012 17:36:20 -0700
- To: Sylvain Galineau <sylvaing@microsoft.com>
- Cc: "www-style@w3.org" <www-style@w3.org>
On Tuesday 2012-04-03 23:58 +0000, Sylvain Galineau wrote: > Overall, the main point is that we may not want animation-fill-mode to 'freeze' > the animation at a particular set of keyframe values, but rather at the interpolated > state of the animation at whatever percentage/point on the time we resolve the fill > to be. Before I engage in the fun exercise of translating that into prose, I wanted > to check whether this made sense to everyone. I agree that it should correspond to a point in time. However, there's the problem (quite common) where that point in time corresponds to a discrete change in the animation. This is well-defined for step functions (which are clear about what happens at their endpoints, I think). And since animations are always value-to-value there are no discontinuities other than a step function within a set of keyframes. However, it's not so well defined when the point in time is at the border of two iterations of the animation (jumping 0% to 100% or from 100% to 0%, depending on 'animation-direction'). For these cases (the 0%/100% boundaries, i.e., the iteration boundaries), we want the state of the animation on the iteration *before* the point in time (but I think we still want its state, in terms of step functions, at the point in time). (Gecko does do this, because I had to write code to handle that case and thus I had to think about it.) This is critical given that the value of 'animation-direction' is 'normal': without this it would mean that an integer 'animation-iteration-count' would jump back to the start of the animation and freeze there, rather than freezing at the end. So I think you need wording describing: * choosing which iteration of the animation to get values from * choosing values from that iteration based on a point in time -David -- 𝄞 L. David Baron http://dbaron.org/ 𝄂 𝄢 Mozilla http://www.mozilla.org/ 𝄂
Received on Wednesday, 4 April 2012 00:36:45 UTC