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

I do believe hover is a specific example where animation reversal  
could be detected.  If you have a set of rules, A, that you match, and  
then you go to matching a new set of rules, B, you could clearly  
detect when you go back to matching the same set of rules as before.   
I believe reversal is the most logical course of action in that case.   
This is rule-based reversal rather than value-based reversal.  For  
changes that result in a different set of rules being matched, I think  
Safari 3.1's current behavior is fine.

dave
(hyatt@apple.com)

On Apr 22, 2008, at 1:02 AM, Maciej Stachowiak wrote:

>
>
> 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 21:07:33 UTC