[css3-transitions] When do transition property changes change already-running transitions?

[L. David Baron]

The css3-transitions spec should answer the question of which
changes to the transition-* properties affect transitions that have
already started.

It seems highly impractical to start transitions for changes that
have already completed if the transition properties change such that
they would still be transition had the transition properties been
set that way when the change originally occurred.

This suggests that it might be best to ignore all dynamic changes to
transition-duration and transition-delay (and probably
transition-timing-function, although that's not as much of an
issue).

And it seems entirely reasonable, and probably most visually
desirable, to run transitions to completion on the same animation
function and timing that they started with.


However, authors sometimes want to stop currently running
transitions.  I think the solution here that imposes the least
inconsistency is the spec saying that running transitions should
stop if the 'transition-property' value changes such that the
property/element pair would no longer transition.  This appears to
be what WebKit does, and is what I plan to implement in Mozilla.

-David

--
L. David Baron                                 http://dbaron.org/
Mozilla Corporation                       http://www.mozilla.com/

[Tab Atkins Jr.]

On Fri, Oct 30, 2009 at 2:45 PM, L. David Baron <dbaron@...> wrote:

> And it seems entirely reasonable, and probably most visually
> desirable, to run transitions to completion on the same animation
> function and timing that they started with.
>
>
> However, authors sometimes want to stop currently running
> transitions.  I think the solution here that imposes the least
> inconsistency is the spec saying that running transitions should
> stop if the 'transition-property' value changes such that the
> property/element pair would no longer transition.  This appears to
> be what WebKit does, and is what I plan to implement in Mozilla.

Agreed with both of these.  Based on my personal and observed use of
transitions via jQuery and other mechanisms, there's really no need to
vary the function/timing of an animation partway through.  However, it
*is* necessary to be able to stop a partially-completed transition,
either to freeze it as it is or to immediately reverse it.

~TJ

[Dean Jackson-7]

On 31/10/2009, at 6:45 AM, L. David Baron wrote:

> The css3-transitions spec should answer the question of which
> changes to the transition-* properties affect transitions that have
> already started.
>
> It seems highly impractical to start transitions for changes that
> have already completed if the transition properties change such that
> they would still be transition had the transition properties been
> set that way when the change originally occurred.
>
> This suggests that it might be best to ignore all dynamic changes to
> transition-duration and transition-delay (and probably
> transition-timing-function, although that's not as much of an
> issue).
>
> And it seems entirely reasonable, and probably most visually
> desirable, to run transitions to completion on the same animation
> function and timing that they started with.
>
>
> However, authors sometimes want to stop currently running
> transitions.  I think the solution here that imposes the least
> inconsistency is the spec saying that running transitions should
> stop if the 'transition-property' value changes such that the
> property/element pair would no longer transition.  This appears to
> be what WebKit does, and is what I plan to implement in Mozilla.

Right, this is what we do in WebKit. The spec should be more clear  
about this.

Dean