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

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.

Dean

Received on Tuesday, 22 April 2008 00:23:09 UTC