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

On Nov 24, 2009, at 5:08 PM, David Singer <singer@apple.com> wrote:

> It sounds like you want asymmetric behavior (transition in, abrupt  
> out) whereupon the rule that Dean wrote wouldn't apply.

Well, I was mostly responding to Tab's case, where he started with "If  
I'm going to be using an asymmetric timing function...". Except I was  
taking duration instead of timing function, but same idea: TJ seemed  
to be saying that even if one of the states (:hover) had an explicit  
non-initial transition value and the other didn't, then unhovering  
would "*always* run in reverse when the state transitions
back to 'normal'", regardless of the computed value of a non- 
explicitly set 'transition-duration' on the non-hover rule, or the  
amount of time hovering. That's how I understood his emphasized  
*always* to mean, and that's what I was debating. If I misunderstood  
what I was arguing against (it wouldn't be the first time), then  
please correct me.

>  It's only in the case where you transition each way and you  
> interuupt the forward to go back again, that most people expect it  
> to back down in the same amount of time as it has taken so far to  
> come up, as it were.

Yes, for symetrical transitions, I would completely agree.

> I think a 'guess of intentions' is needed here.  I think the  
> duration has to be 'right' (shorter);  whether the function has to  
> be perfectly reversed I am less clear.  And delays confuse me.

I think I would have to see a few examples of different uses to know  
what feels more natural. You probably have a better sense of that than  
I do right now.


> On Nov 24, 2009, at 16:47 , Brad Kemper wrote:
>
>> On Nov 24, 2009, at 2:28 PM, "Tab Atkins Jr."  
>> <jackalmage@gmail.com> wrote:
>>
>>> 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.
>
> David Singer
> Multimedia and Software Standards, Apple Inc.
>

Received on Wednesday, 25 November 2009 03:22:07 UTC