Re: Updated versions of Apple's transforms/animations/transitions proposals

[sorry for the top post -- also, it seems like attribution/quoting is  
wrong below]

Suppose a property is transitioning from A to B, and partway through  
it is told to go to C. I think you have 3 options:

1. You go to C using the specified transition duration (a new  
transition).
2. You go to C using the remaining duration from the AB transition.
3. You go to C using the duration that the AB transition has been  
running.

Option 1 is what is currently implemented in WebKit (I believe).  
Option 2 would probably feel more natural in most cases. Option 3 is  
what people probably expect if C == A (it reverses the effect).

I think allowing the author to choose might be the best option.

In each case the starting point is the intermediate property value  
between A and B. Is there a need to restart the transition from A?

A further note for reversing a running transition: would an author  
ever want the animation to play in something other than the exact  
reverse? For example, suppose you have a non-linear timing function.  
Would you want the reversed animation to use the same partial  
function, or the reverse of the partial function? Again, maybe this  
should be an option.

Now the trick is to specify all this without adding lots of ugly new  
properties.

Dean

On 17/04/2008, at 7:22 AM, Robert O'Callahan wrote:
> On Thu, Apr 17, 2008 at 3:58 AM, Maciej Stachowiak <mjs@apple.com>  
> wrote:
>
> On Apr 15, 2008, at 4:24 AM, Robert O'Callahan wrote:
>> On Tue, Apr 15, 2008 at 9:31 PM, Mikko Rantalainen <mikko.rantalainen@peda.net 
>> > wrote:
>>
>> This means that if the current position is not "fully zoomed" (in  
>> case
>> of fisheye demo), the transition (the speed of the movement/ 
>> zooming) is
>> slower than it would be normally but it takes as long as the full
>> movement would take.
>>
>> That may look OK in some cases but in other cases it won't. I hope  
>> that's not what gets specified.
> For really smooth handling of reversing a transition only a short  
> way in, it may be desirable to specify transition velocity rather  
> than duration.
>
> Duration is simpler for authors than velocity, especially since CSS  
> can't express division easily. What I was thinking of have authors  
> specify duration, but compute the velocity by dividing the distance  
> from the old target value to the new target value by the duration,  
> and use the velocity internally instead of the duration, so if our  
> current actual value is closer to the new target than expected, the  
> animation is shorter than the specified duration, or if the actual  
> value is further away than expected the animation lasts longer than  
> the specified duration.
>
> Or maybe you allow the former case but not the latter, so the actual  
> duration can be less than the specified duration but not greater.
>
> Another possibility is Hyatt's suggestion of detecting reversal,  
> since that is typically the only way you see a very small transition  
> over a long duration.
>
> That sounds a bit fragile. For example an element might have  
> multiple states and we want to animate the transitions between them;  
> we might be transitioning from state A to state B and then suddenly  
> decide we want state C instead, which is closer to A than B on some  
> property axis.
>
> I'm hoping you are objecting only to the "full duration" part of the  
> above, not starting from the current (possibly mid-transition) state  
> when beginning a new transition.
>
> Of course! Continuity is essential.
>
> Rob
> -- 
> "He was pierced for our transgressions, he was crushed for our  
> iniquities; the punishment that brought us peace was upon him, and  
> by his wounds we are healed. We all, like sheep, have gone astray,  
> each of us has turned to his own way; and the LORD has laid on him  
> the iniquity of us all." [Isaiah 53:5-6]

Received on Friday, 18 April 2008 21:50:07 UTC