Re: [transitions/animations] stepped timing function proposal

Something I have wondered about with my colleagues and reached no firm conclusion on is whether (using the same terminology as this message) we need a timing function step-start-end.  This would have the semantics

for N>1, a transition happens at T=0 and also at T=duration, and the others (if any) are equally spaced in the interval.

This has the two advantages (a) it's symmetric and (b) 'something happens' at the beginning and end of the period I set, rather than one end being offset from the period end.
(for N=1, the transition happens at t=(duration/2), probably, for completeness, though I doubt it's useful)



On Feb 23, 2010, at 15:14 , Simon Fraser wrote:

> On Jan 19, 2010, at 2:50 PM, Dean Jackson wrote:
> 
>> I propose a new value for the "animation-timing-function" property, allowing a value to jump instantly from one keyframe to another, rather than be interpolated.
>> 
>> A good example of why this is useful is the progress spinner on OSX which could be implemented as an infinite rotation. Also, this feature is in SMIL/SVG [1] as calcMode="discrete". However, I think we should consider going one step beyond what SMIL suggested and allow the step to happen either at the beginning or end of the keyframe.
>> 
>> jump-start
>>  There is no interpolation. The property instantly changes to the end value as soon as the animation begins.
>> 
>> jump-end
>>  There is no interpolation. The property remains at its start value until the animation ends, at which point it instantly changes to the end value.
> 
> I prefer:
> 
> step-start, step-end;
> 
> I'd also like to extend this proposal to allow the author to specify that the change occurs in a number of discrete, equal steps, rather than just one. This would be achieve by allowing a two new functional values in the transition-timing-function property:
> 
> step-start(<number>), step-end(<number>)
> 
> step-start(1) is equivalent to step-start, and step-end(1) is equivalent to step-end. The functional version does not need to have the same name; suggestions are welcome.
> 
> To explain further, step-start(N) causes the value to change in a series of N steps of equal size. The first step occurs the instant that the transition starts (which is after the delay, if transition-delay is non-zero). The next N-1 steps occur at regular time intervals over the duration of the transition. The property reaches its final value D/N seconds before the end of the transition period, where D is the duration.
> 
> step-end(N) causes the value to change in a series of N steps of equal size. The first step occurs D/N seconds into the transition, where D is the duration, and the remaining steps occur at regular intervals over the remainder of the duration. Thus, the last step occurs at the end of the transition period.
> 
> Both step-start and step-end exist so that an author can create symmetrical transitions, for example when entering and leaving a :hover state.
> 
> A good use case for step-wise timing functions is in recreating the Mac OS X spinning progress indicator:
> <http://www.codeproject.com/KB/progress/AsyncProgressControl/CircularControl.JPG>
> This is a circular image that has 12 tick marks. When animating, it doesn't rotate smoothly, but jumps around in 24 steps. There is no way to recreate that effect with CSS transitions or keyframe animations (without unwieldy keyrame hacks) unless we have step-wise timing functions.
> 
> David Baron previously suggested that we support transition-delay to non-animatable properties:
> <http://lists.w3.org/Archives/Public/www-style/2009Nov/0328.html>
> 
> Non-animatable properties could also be affected by transitions if the timing function is one of the single-step variants, which would give the author control over when the change happens in relation to other properties that may be transitioning.
> 
> Simon
> 

David Singer
Multimedia and Software Standards, Apple Inc.