This might be really easy to implement with the new base of code in 1.8 -- If we want to, I suppose now would be the time to do it?

Not sure about the use cases and semantics here. Actual events, or just callbacks? If callbacks, would these be added to the property hash or to the arg list? If events, would the event be fired on the element being animated and would it bubble, which would be relatively expensive?

Callbacks - the "options" hash.

$.fn.animate( props, opts );

opts = {
    start: // called during animation startup ( after prefilters)
    complete: // called when animation plays its last frame - not called when interrupted early
    stopped: // called when animation is stopped early ( has a boolean indicating "gotoEnd" )
    always: // called when animation is done
};

I'm not happy with the name "always", but I like it more than "finish" since finish seems to imply the animation completed. "complete" currently is the only defined callback.

start seems useful, stopped could also be useful, and "always" (or a better name) more so...

I'd also like to propose that the "first argument" to each of these functions (none is currently defined for "complete" ) be the "animation" object from jQuery 1.8.

Just to go over the expected calling for various ways an animation finishes, when an animation is stopped by:

.stop( false, true /*gotoEnd*/ )

 stopped( anim, true ) 

 complete( anim  

 always( anim ) 

.stop( false, false )

 stopped( anim, false ) 

 always( anim ) 

natural completion - calls

 complete( anim ) 

 always( anim ) 

Why come so close to Promise without going all the way?

• .stop( false, gotoEnd = true ) calls:

1. done( anim, jumpedToEnd = true )

2. always( anim, jumpedToEnd = true )

• .stop( false, gotoEnd = false ) calls:

1. fail( anim, jumpedToEnd = false )

2. always( anim, jumpedToEnd = false )

• natural completion calls:

1. done( anim, jumpedToEnd = undefined )

2. always( anim, jumpedToEnd = undefined )

and let done fallback to complete for backwards compatibility.

Maybe it is just that simple... +1 gibson

I like that, and prefer it to creating new callbacks.

Will it be good to have another event/callback for animation progress.

I think it should be fired in each frame of animation.

The event should have properties like

status (notStarted, Running, Completed, Aborted/interrupted) and

progress (the progress percentage)

I know it will cost processor time. But it will be useful for tracking event percentage and also it will make jQuery's animation much flexible.

Replying to [comment:7 imdad.sk@…]:

Will it be good to have another event/callback for animation progress. I think it should be fired in each frame of animation. The event should have properties like status (notStarted, Running, Completed, Aborted/interrupted) and progress (the progress percentage) I know it will cost processor time. But it will be useful for tracking event percentage and also it will make jQuery's animation much flexible.

There are other ways to get this information, also there is currently the

step

https://github.com/jquery/jquery/pull/830

Fix #11797. Use Deferred for better animation callbacks. Closes gh-830.

In particular, an animation stopped with gotoEnd will be rejected.

Changeset: 36369ce50ff276dcf2959add7dc949af83b221c2

Replying to [comment:7 imdad.sk@…]:

Will it be good to have another event/callback for animation progress. I think it should be fired in each frame of animation.

On second thought, this is way too useful... Filing a pull request to amend in the "progress" callback which is

 function( anim, progress, remainingMS ) 

https://github.com/jquery/jquery/pull/835

#11910 is a duplicate of this ticket.