RE: more transitionend events (was Re: when do transitions occur?)

Like David, I also question the utility of throwing events where a property is being set to the same value. It seems like a stretch, and sounds like a scenario where the author wants a different mechanism to achieve one's goals.

Yet I agree that it may make sense to fire transition events even when there is 0 delay and 0 duration especially because it keeps animations behavior and transitions behavior aligned. Are there any concerns against throwing the event in this case aside from performance?

-----Original Message-----
From: L. David Baron [] 
Sent: Wednesday, September 21, 2011 1:30 PM
To: Dean Jackson
Cc: Jennifer Yu; Brian Manthos; Tab Atkins Jr.;
Subject: more transitionend events (was Re: when do transitions occur?)

On Thursday 2011-09-22 06:17 +1000, Dean Jackson wrote:
> On 16/09/2011, at 6:37 AM, Jennifer Yu wrote:
> > Thanks for the responses Tab and David. I didn't realize that shorthands don't have a computed value since getComputedStyle seems to return a valid string for shorthands.
> > 
> > And just for clarification regarding zero duration transitions and animations (since I seem to have trouble finding the previous discussion of it), 0 duration transitions should not throw events if the delay is also 0. If the delay is positive, 0 duration transitions should throw an event. 0 duration animations, on the other hand, should throw events. Are those statements accurate?
> We get a *LOT* of requests from developers asking for transitionend events to fire all the time, even if the property didn't change. This could be a 0/0 duration delay, or setting a property to the same value.
> The use case is generally wanting to run a bunch of animations on children before changing a parent. Think of something like a slide-show where the text might slide off the page before the transition to the next screen.
> Any opinions on this?
> We're concerned about performance impact. An alternative would be to write an API that allows you to query the current state of all transitions on an element (or subtree). That way you'd know what is active.

I'm not sure what it even means.  Transitions start when a computed value changes; are you saying you'd introduce cases where transitions occur even when a computed value doesn't change?

It sounds to me like the use case that these authors have is probably best solved by a mechanism other than transitions, and one that should be designed to be able to do what they want efficiently.


𝄞   L. David Baron                  𝄂
𝄢   Mozilla                    𝄂

Received on Tuesday, 27 September 2011 19:49:59 UTC