W3C home > Mailing lists > Public > www-style@w3.org > November 2009

Re: [css3-transitions] faster reversing of partially completed transitions

From: Brad Kemper <brad.kemper@gmail.com>
Date: Tue, 24 Nov 2009 16:47:29 -0800
Message-Id: <EC4530BC-7737-461B-A72E-AF7EC53E2AE4@gmail.com>
To: "Tab Atkins Jr." <jackalmage@gmail.com>
Cc: "L. David Baron" <dbaron@dbaron.org>, "www-style@w3.org" <www-style@w3.org>
On Nov 24, 2009, at 2:28 PM, "Tab Atkins Jr." <jackalmage@gmail.com>  

> If I'm going to be using an asymmetric timing
> function for state transitions, though, as an author I'm going to
> expect that they *always* run in reverse when the state transitions
> back to 'normal'.  This includes transition-delays.  I'm not thinking
> of the transition from :link to :hover to :link as two independent
> changes, I think of them as being a change and then a reversal of that
> change.

But you could think of them as two independent changes, and set the  
transition on each. I think that would be better than the UA trying to  
guess your intentions. I don't think I would expect it to run in  
reverse, unless (possibly, and that's the question) it hadn't finished  
running in forward. If you didn't set the :link version (or the no  
pseudo-class version), then unhovering would cause an abrupt change  
back. If that's what you wanted (and sometimes it might be), you'd be  
done; if not, you'd notice pretty quick and know what to do to fix it.

I can imagine, for instance, wanting a tooltip thingy that faded in  
(with opacity) after a second or two delay when hovering, and then  
disappearing to opacity:0 abruptly as soon as I moved the cursor away.  
If it was only half opaque, I would want the change back to be just as  
abrupt (with no delay or duration) as it would have been if the first  
transition had played out. I would expect that to happen if I didn't  
set any transition values on the :link, because the initial transition- 
duration without me setting it would be 0. 
Received on Wednesday, 25 November 2009 00:48:21 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:07:40 UTC