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

On Tue, Nov 24, 2009 at 3:51 PM, L. David Baron <dbaron@dbaron.org> wrote:
> 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).

That's a problem.  If I'm going to be using an asymmetric timing
function for state transitions, though, as an author I'm going to
expect that they *always* run in reverse when the state transitions
back to 'normal'.  This includes transition-delays.  I'm not thinking
of the transition from :link to :hover to :link as two independent
changes, I think of them as being a change and then a reversal of that
change.

Is there some way to codify that concept?  If so, we'll simultaneously
address author expectations and have a tool to properly resolve this
issue (just treat transitions from A->B->A as 'reversing' a state
change).

~TJ

Received on Tuesday, 24 November 2009 22:29:47 UTC