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

On Feb 24, 2011, at 2:20 AM, louis-rémi BABE wrote:

> 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
> implementations:
> 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
> prematurely.

The current editor's draft is a bit more specific about when
transitions start, and what happens when the transition properties change
during a transition:
<http://dev.w3.org/csswg/css3-transitions/#starting>

> 
> 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.

True.

> 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.

The reasoning here is that if you do something in script that causes the transition
to be interrupted, you know that, so have no need for an event.

I can see the utility of firing an event for interrupted transitions, but maybe a
different event should fire in this case?

> 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_.

CSS transitions are intended to be used mostly without any associated script.
They are just a very simple way to interpolate between property values.

If you have close ties between your CSS and script, then it may be more appropriate
to use CSS Animations, where you get more control and more events.

Simon

Received on Thursday, 24 February 2011 19:23:15 UTC