[css3-transitions] faster reversing of partially completed transitions

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.


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

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 Tuesday, 24 November 2009 21:52:26 UTC