Re: [css3-transitions] faster reversing of partially completed transitions

On 25/11/2009, at 8:51 AM, L. David Baron wrote:

> Dean added a new section on reversing of partially-completed
> transitions: http://dev.w3.org/csswg/css3-transitions/#reversing
> This is intended to solve a problem that shows up in WebKit's
> implementation:  for example, if an element has a transition for a
> style that changes on :hover, and the user moves the mouse into the
> element (starting the transition) and then out of the element well
> before the transition repeats, the movement back to the original
> position ends up much slower than the movement away from it, since
> it uses the full transition-duration for just a partial change in
> the movement.
>
> I'd implemented a different approach for fixing this in Mozilla.
> There, I'd actually used distance computation (the code for which is
> required for paced animation in SMIL, although perhaps not for as
> many value types as we want to support transitions on).  So I
> computed the ratio of:
> (a) the distance between the current (in-transition) style and the
>     new style
> (b) the distance between the endpoint of the current transition and
>     the new style
> and if this ratio was less than 1, I simply multiplied the
> transition-duration by this ratio (and, if the transition-delay was
> negative, also multiplied the transition-delay by it).  Then I ran
> the original function on the delay.
>
> However, I was already thinking of changing this approach, since I
> wasn't sure I wanted to support distance computation on all value
> types (I think it starts getting harder once calc() is introduced;
> though without calc it's relatively straightforward to come up with
> a distance measure whose ratios are meaningful, even if it doesn't
> have any meaningful units).  In other words, I was thinking of
> changing to an approach that (like Dean's) would only handle the A
> to B to A case and just run transitions as specified if they aren't
> exactly reversed.

Out of interest, did the distance computation approach "feel" right?

> One thing I'm concerned about with the text that Dean added to
> http://dev.w3.org/csswg/css3-transitions/#reversing is that it
> introduces the concept of running a transition function in reverse.
> I'm a little uncomfortable with introducing that concept only here,
> but not anywhere else in the spec.  It would create discontinuities:
> for example, if an element has an 'ease-in' or 'ease-out'
> transition-timing-function for an effect that happens much like in
> the :hover example above, you'll get an entirely different effect if
> the mouse moves out of the element just before the initial
> transition completes (you'd essentially get whichever of
> ease-in/ease-out wasn't specified) vs. just after the initial
> transition completes (in which case you'd get ease-in or ease-out as
> specified).

Yeah, this is a problem. We've discussed lots of different approaches
internally at Apple but didn't find anything flawless. I'm sure
there will be cases when people don't want reversability.
>
> If we don't do that, the question is what to do instead.  I can
> think of a two other possibilities:
>
> (1) shorten the transition-duration (and any negative
>    transition-delay) by the ratio of the time elapsed so far in the
>    initial transition to the total time of that transition (much
>    like what I did above, except using time instead of distance)
>
> (2) jump to the point in the timing function (at the specified
>    transition-duration) for the reverse transition that would have
>    the element at its current position (and thus ignore
>    transition-delay entirely)
>
> Either of these could be combined (or not) with reducing positive
> transition-delays, though my initial inclination would be not to do
> so.
>
> -David
>
> -- 
> L. David Baron                                 http://dbaron.org/
> Mozilla Corporation                       http://www.mozilla.com/
>

Received on Thursday, 26 November 2009 03:51:52 UTC