On 6/7/09 7:39 AM, L. David Baron wrote:
The simplest case is that of a transition in progress (transitioning
from A to B) in which the property value is changed back to A before
the transition completes. I think this is probably the case that we
want to optimize for, since I expect it to be the most common.
However, other cases should behave reasonably.
The issues that introduce complexity (that I can think of) are:
* transitions follow author-provided timing functions. These may
or may not be symmetric (and the default, 'ease', is not).
* the transition-delay property (which doesn't seem to be
implemented in WebKit, but which I have in the implementation I'm
working on) allows a delay before the transition starts
This can be thought of as just a parameter that alters the shape of the
timing function, right?
* the change in value that interrupts a transition from A to B
(i.e., the result of a style change from A to B) might not be
back to A. It could be to a value between A and B, a value past
B, or a value back on the other side of A.
The behavior I have currently implemented (because it was the
easiest, not because it's what I want) is that whenever the value is
changed, the current (mid-transition) value is used as the starting
point, but no adjustments are made to the timing function or delay.
This behavior doesn't seem very good in a common case: a transition
for a style change that occurs due to :hover, in which the mouse is
moved off the element very quickly.
I think that's what Webkit currently does.
However, if we want to do something better, it's not clear to me how
to incorporate the timing function and the delay, and whether (or
how) to incorporate the timing function of the in-progress
transition.
I could imagine approaches that make the "starting point" of one
transition be the current position / endpoint of the previous. I
could also imagine approaches that try to act as though the return
transition was complete rather than from the midpoint, except
jumping in in the middle of the timing function. And I can also see
starting from the in-progress point (as I am now) but adjusting the
transition duration (and the delay?) proportionally based on how
much of the previous transition completed. I'm not sure how well
any of these would work, though.
Does anybody have opinions on how this should work, or pointers to
existing solutions of this problem?
This was discussed a fair bit in www-style, but I don't think anything
was resolved.
I used to think that if you're in the middle of a transition from A to
B, and the destination is reset to A, then you probably want to reverse
the transition you've executed so far. This seems likely for things like
hover effects, where you're trying to give the feel of springiness or
elasticity.
But if the transition to B completes and then the value is reset to A,
do you want that transition to run in reverse as well? Seems to me that
in some cases (springy hover effects) you would, but in other cases you
wouldn't.
Maybe this is a totally crazy idea, but could you compare the
specificities of the rules setting the property value for the "old
value" and "new value"? If the specificity decreases, then run the
transition function in reverse. So if you add a class or pseudo-state,
do a transition, then remove the class or pseudo-state, the transition
runs in reverse.
Rob
_______________________________________________
dev-tech-layout mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-tech-layout
