W3C home > Mailing lists > Public > www-style@w3.org > April 2008

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

From: Maciej Stachowiak <mjs@apple.com>
Date: Mon, 21 Apr 2008 16:43:26 -0700
Cc: Dean Jackson <dino@apple.com>, Mikko Rantalainen <mikko.rantalainen@peda.net>, www-style@w3.org
Message-Id: <7A1DAF97-FC38-4DC3-B6AB-7440C147756D@apple.com>
To: robert@ocallahan.org

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.

Received on Monday, 21 April 2008 23:44:19 UTC

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:27:35 UTC