[css3-transitions] What should happen when a value is changed midway through a transition?


I'm working on building css3 Transitions into jQuery animation
component, trying to reach feature parity with js based animations.

I'm facing numerous issues, both with the specification and current
1. All js libraries offer a way to complete animations prematurely
(e.g. http://api.jquery.com/stop/ &
http://mootools.net/docs/core/Fx/Fx#Fx:cancel ).
   It is not currently specified how this could be achieved, although
Chrome and Firefox make it possible by removing a property name from
the transition-property list.
   I would also expect that setting the duration of the transition to
0 would produce the same effect.
   This should be clearly specified as ways to complete a transition

2. All js libraries offer a way to stop animations midway through
(e.g. http://api.jquery.com/stop/ &
http://mootools.net/docs/core/Fx/Fx#Fx:pause ).
   This is currently possible in all browsers implementing css3
Transitions by setting a property to its current computed value.
   This could be clearly specified as a way to stop a transition
midway through.

3. All js libraries can run a callback function when the transition
completed, _no matter how and when it completed_ (e.g.
http://api.jquery.com/animate/ &
http://mootools.net/docs/core/Fx/Fx#Fx:constructor ).
   It is specified that "The completion of a CSS Transition generates
a corresponding DOM Event.". However, current implementations do not
generate a transitionend event immediately when transitions complete
prematurely and do not generate transitionend event at all when the
transition is stopped midway through.
   It should be clearly specified that a transitionend event should
be generated immediately in both cases.

More controversial but important issue:
4. All js libraries can run a callback function after a certain
duration even though no property was animated. For example, if the
current width of an element is 100px and I program an animation to
100px during 1 second, the callback is going to run after 1 second
anyway. The library "doesn't care" that the initial & final width is
the same, all it knows is that an animation was programmed for a given
duration so the callback must fire after this duration.
   Using css3 transitions the code would look like:
// setup element
var div = document.createElement('div');
div.style.width = '100px';
// setup transition & callback
div.style.transition = width 1s linear;
div.addEventListener( 'transitionend', function() {
console.log('complete') }, false);
// program (null) animation
div.style.width = '100px';
   It is not specified that this should be feasible and current
implementation do not allow it: no transitionend event is generated if
no visual animation happens. I don't think this is the expected
behavior because the transitionend event is not supposed to mean "this
property was actually animated" but rather "this property reached its
'target value'". Additionally, it would be a real pain to build css3
transitions into js libraries in a backward compatible way: this would
mean accessing the current value of each property, checking that it is
not the same as the target one (special checks for min/max-width,
min/max-height compared to the current width) and creating a timeout
to emulate the transitionend even if both values are equal. Those
additional DOM access would negatively impact the performance of
Transitions, a very unfortunate consequence when performance is
supposed to be a key aspect of this css3 feature.
   In a way, this behavior conflicts with my third expectation, as
the transitionend event should not be generated immediately although
the transition apparently already completed.
   It should be clearly specified that when a property (contained in
the transition-property list) is set to its current value, if it is
not currently animated, a transitionend event should be generated
_after the transition duration_.

I have built reduced test cases for all but the last of these
expectations on http://csstransition.net

Thank you in advance for your feedback,


Received on Thursday, 24 February 2011 10:21:25 UTC