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

On Apr 21, 2008, at 5:21 PM, Dean Jackson wrote:

>
> On 22/04/2008, at 9:43 AM, Maciej Stachowiak wrote:
>>
>> On Apr 17, 2008, at 7:14 PM, Robert O'Callahan wrote:
>>> On Fri, Apr 18, 2008 at 1:40 PM, Dean Jackson <dino@apple.com>  
>>> wrote:
>>> 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.
>>>
>>> My guess is, if the duration of the AB transition equals the  
>>> duration of the new transition, then authors want case 2 if C is  
>>> close to B, and case 3 is C is close to A.
>>>
>>> Hmm. I think Maciej was on the right track and we really want to  
>>> specify velocity, not duration, or perhaps a desired velocity and  
>>> a maximum duration. It's too bad that specifying velocity in CSS  
>>> seems hard :-(.
>>
>> You could specify a duration and an expected amount of change, and  
>> use that to infer a velocity. Or perhaps there is some way to infer  
>> "expected amount of change", perhaps we determine this every time a  
>> transition affects an element and no other transitions are  
>> currently in effect on it. So every transition that doesn't  
>> interrupt another gets full duration, but mid-course reversals  
>> would have the duration adjusted by the distance to go.
>>
>> I think that would handle the quick reversal case nicely without  
>> additional properties.
>
> I'm not (yet) sure that we should have this behaviour as the  
> default. What is currently specified looks wrong in some cases, but  
> I'd like to see more real-world content and possibly a prototype  
> before changing things.
>
> I think the idea has a lot of merit though.

I'm pretty confident from all the test content I have seen that the  
currently specified behavior is bad for hover effects on many adjacent  
items, because the "quick reversal" scenario comes up very readily  
when scanning across items.

I am less confident of the merits of my proposed change, since my  
description is very vague and we have yet to see it in action.

Cheers,
Maciej

Received on Tuesday, 22 April 2008 18:32:53 UTC