When we discussed CSS transitions, one of the issues that was mentioned as an advantage of declarative animations is that we can set them up to automatically behave reasonably when an animation is stopped or reversed in the middle of the animation. I've been trying to figure out what should happen here to improve my current implementation, but I'm not quite sure what the ideal behavior is. My memory from the discussion we had at various feature planning meetings is that some other people had stronger opinions than I did about this, so I'm hoping somebody else knows more about this than I do.
The simplest case is that of a transition in progress (transitioning from A to B) in which the property value is changed back to A before the transition completes. I think this is probably the case that we want to optimize for, since I expect it to be the most common. However, other cases should behave reasonably. The issues that introduce complexity (that I can think of) are: * transitions follow author-provided timing functions. These may or may not be symmetric (and the default, 'ease', is not). * the transition-delay property (which doesn't seem to be implemented in WebKit, but which I have in the implementation I'm working on) allows a delay before the transition starts * the change in value that interrupts a transition from A to B (i.e., the result of a style change from A to B) might not be back to A. It could be to a value between A and B, a value past B, or a value back on the other side of A. The behavior I have currently implemented (because it was the easiest, not because it's what I want) is that whenever the value is changed, the current (mid-transition) value is used as the starting point, but no adjustments are made to the timing function or delay. This behavior doesn't seem very good in a common case: a transition for a style change that occurs due to :hover, in which the mouse is moved off the element very quickly. For example, suppose that an element has 'left' change on :hover, with a 3s linear transition, but the mouse pointer moves off it after half a second. With the implementation above, the position of the element then moves back to its original position at 1/6 the speed that it moved away from that position, which clearly seems wrong. However, if we want to do something better, it's not clear to me how to incorporate the timing function and the delay, and whether (or how) to incorporate the timing function of the in-progress transition. I could imagine approaches that make the "starting point" of one transition be the current position / endpoint of the previous. I could also imagine approaches that try to act as though the return transition was complete rather than from the midpoint, except jumping in in the middle of the timing function. And I can also see starting from the in-progress point (as I am now) but adjusting the transition duration (and the delay?) proportionally based on how much of the previous transition completed. I'm not sure how well any of these would work, though. Does anybody have opinions on how this should work, or pointers to existing solutions of this problem? -David -- L. David Baron http://dbaron.org/ Mozilla Corporation http://www.mozilla.com/ _______________________________________________ dev-tech-layout mailing list [email protected] https://lists.mozilla.org/listinfo/dev-tech-layout
