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

Re: Transitions and Animation merging: problem summary

From: Andrew Fedoniouk <news@terrainformatica.com>
Date: Fri, 16 Apr 2010 20:07:04 -0700
Message-ID: <E4DA5413F3E94494B2661AA55F1F19FA@terra3>
To: "Chris Marrin" <cmarrin@apple.com>, "Tab Atkins Jr." <jackalmage@gmail.com>
Cc: "Brad Kemper" <brad.kemper@gmail.com>, "W3C Emailing list for WWW Style" <www-style@w3.org>

From: "Chris Marrin" <cmarrin@apple.com>
Sent: Friday, April 16, 2010 5:28 PM
To: "Tab Atkins Jr." <jackalmage@gmail.com>
Cc: "Brad Kemper" <brad.kemper@gmail.com>; "W3C Emailing list for WWW Style" 
Subject: Re: Transitions and Animation merging: problem summary

> On Apr 16, 2010, at 10:57 AM, Tab Atkins Jr. wrote:
>> On Fri, Apr 16, 2010 at 10:28 AM, Chris Marrin <cmarrin@apple.com> wrote:
>>> Sorry, this is a detail of an issue that I thought was well known. 
>>> Currently, when a transition is triggered while running (by setting a 
>>> new value in the property being transitioned) an entirely new transition 
>>> is started. So if you are 0.1 seconds into a 2 second transition and you 
>>> set the property back to its starting value (as you would when you 
>>> unhover) going back to that starting value will take 2 seconds, not 0.1 
>>> as might be desirable. So it would be useful to add reversible 
>>> transitions to the spec and define the rules for when they occur. But as 
>>> I said, that's a conversation for another thread.
>>> Does that make it more clear?
>> Such details *are* already in the spec.  ^_^
> Urgh, I didn't realize that had already been added. In that case, I 
> retract my comment that this needs discussion. But I still believe 
> reversing transitions in this way is important whereas for animations it 
> is not. That was a much more noisy explanation than it needed to be :-)

Let's imagine that 'animate' is defined as:

animate[-in/out]: <property> || <ease-function> ||  <step-duration> || 
<start-delay>[ || <number-of-steps>]

Rule of animation reversal is pretty simple: all not finished steps are 
The desire is to see elements eventually in the same state as they were 
this [canceled] animation but without "jumps".
Another option would be to complete unfinished states if  number-of-steps is
defined and is greater than one.

Andrew Fedoniouk


Received on Saturday, 17 April 2010 03:07:36 UTC

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:38:34 UTC