- From: Dean Jackson <dino@apple.com>
- Date: Thu, 26 Nov 2009 14:51:11 +1100
- To: L. David Baron <dbaron@dbaron.org>
- Cc: www-style@w3.org
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