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

2011/2/24 louis-rémi BABE <lrbabe@gmail.com>:
> 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.

Do you mean that, if a transition completes prematurely, browsers
currently still only fire the transitionend event at the original
end-time of the transition?  That sounds like a bug.

If a transition is stopped midway through by removing the property
from the transition list, I don't think it should fire a transitionend
event - the transition didn't end, it was forcibly deleted.  Stopping
it by setting the duration to 0 should still fire an event
immediately, though.


> 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');
> document.body.appendChild(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_.

This would not be a good thing.  You're thinking from the simple case
of "I set a value in script, so it should infer that I want a
transition to happen (even if the value didn't actually change)".
Your proposal would do more than that, though - it would cause a
transition to happen in cases like this:

<style>
p { color: black; transition: color .2s; }
p.a { width: black; }
p.b { width: red; }
p.c { width: blue; }
</style>
<script>
document.querySelector('p').classList.add('a');
</script>

In this case, it is *not* obvious that the intention was to force a
transition, and getting spurious transitionend events may be unwanted.

What you want instead is a proper imperative animations API that hooks
into the Transitions/Animations model, so you can manually kick off an
animation and have control over exactly how it works.

~TJ

Received on Thursday, 24 February 2011 17:36:20 UTC