I’d go for 3 (not called). If your goal is to fire in progression and the intended animation is paused or interrupted so should the progression. I’d also look at Greensocks tweenlite or tweenmax and how they go about it.
Am I wrong in thinking if you introduced this as a feature you would be able to have a set of result codes to check against which would include codes for such interruptions and allow you to handle them depending on the result code?.
I was still thinking about this. Using a complete handler is a valid way to implement the initial temporal cascade and is done so in TweenLite. But Hype has already the built in concept of a timeline that might also be a solution, given one could create a virtual timeline and add actions to it through code. One then could use all the usual and already known operations on it like play, stop and jumps to specific time indeces. That logic is already implemented in the runtime.
The setProperty-Call-Chain discussed here also could be added via an extension but also introduces a complete new stack of things to worry about and keep track of. Guess it would be the easier fallback if Hype doesn’t expose a proper virtual timeline API, though.
In fact, setElementProperty does make a timeline under-the-hood, so the most basic implementation of a callback is adding a timeline action at the end. This is what brought up my question of behavior; this timeline action would currently be called even if the property became owned by a different timeline, and I wasn’t sure this was in line with expectations. It would be interesting to expose the timeline identifier for control along with giving the ability to add animations/timeline actions to it.