Considering that the sets of elements for .stop and .promise are not necessarily identical, much would have to be decided about under which circumstances—and when—to fail a .promise. This could easily get very messy, and I think I'd be against changing the behavior for that reason alone.

Do the new-in-1.8 animation callbacks solve your use case? They're not yet well-documented, but we're working on it (https://github.com/jquery/api.jquery.com/issues/61, https://github.com/jquery/api.jquery.com/issues/81).

I've updated your example to show how you might take advantage of them: http://jsbin.com/ayobuh/10/edit

I agree with gibson042 here. If the first *xxxx* stop()ped animation failed the collection, for example, you wouldn't know when the unfailed animations completed.

We already provide the tools to solve this. The code stopping the animation isn't some remote external force, so it can easily coordinate a signal with other code in the app. For example, to get a failed promise you could join both the animate promise and a second promise that you .reject() in the function where .stop() is called. Wrap it all up in your own method to keep it DRY.

http://jsbin.com/ayobuh/12/edit

Thanks for showing me the new syntax. It does deliver what I think is vital: a way to know whether the animation ran till the end with "complete" and "done" or if it got stopped, with "fail". It sounds weird that whatever deferred object is used inside the animate function, is not the same that is passed on the promise object though.

So I still think that promise().done() should be triggered only when animation went till the end, and that promise().fail() should be triggered in that case.

Otherwise, what else could it mean, semantically, right? I think "fail" is closer to stopped then "done".

Thanks once again from sunny Brazil,

The problem is that .promise doesn't cover ''the'' animation; it covers all pending actions in a single queue for all elements in the jQuery collection. Semantically, resolution of the promise indicates that those actions are no longer pending, and it's not clear to me how we could provide a meaningful rejection.

The promises for a particular animation (that resolve/reject in the way you expect) are passed as the first argument to .animate callbacks, including start.

I don't see a way for .promise to satisfy this ticket without breaking existing code, but @dmethvin's example could be generalized into a plugin.