[css-transitions] transitionstart definition does not match Edge behavior

[birtles]

CSS Transitions Level 2 defines the transitionstart event as being fired "when a transition is started (i.e., when it is added to the set of running transitions)".

However, Edge is already shipping a transitionstart event that fires at the end of the delay as demonstrated in this fiddle: https://jsfiddle.net/jph4eo2o/

Making transitionstart fire at the end of the delay is consistent with animationstart. However, it is less useful for authors who want to determine whether a given style change triggered the creation of a new transition or not (e.g. so they know if they should wait for transitionend events before considering the element to be in a stable state).

Perhaps we need a separate event for when a transition is created, transitionfire or something of the sort?

[nolanlawson]

Just a quick note because it wasn't clear to me from your post: based on the fiddle, I see Safari/FF/Chrome are not shipping the transitionstart event yet, but Edge is (and as you say, it fires at the end of the delay).

So we can safely assume the event isn't in wide use "in the wild" yet, which is nice because it gives us some wiggle room.

/cc @gregwhitworth

[birtles]

Yes, that's right. We're implementing this in Firefox at the moment hence we want to clarify this. There's a bug on file for Chrome, but no activity yet. I mentioned it to a couple of friends at Google earlier this week so I suspect they'll pick it up soon.

If Edge are prepared to change their implementation to match the current spec behavior we'll stick with that, otherwise we might need a new event.

For what it's worth, the particular use case I have in mind is that when we were working on Firefox OS apps we often wanted to wait until transitions had finished before updating some piece of state. However, in some situations transitions would get cancelled such as when a DOM subtree gets replaced (i.e. "rendered" if you're using a framework like react). As a result the transitionend event would never fire. Instead, we'd often end up setting timeouts to run in case the transition got cancelled. The transitioncancel event is supposed to help with that but there are still situations where you might not get a transition to begin with, e.g. if you update style but the new style values happen to match the old ones, so you still might find you're waiting for an event that never comes. Having an event that fires when a new transition is triggered would let you know that you need to wait for either transitionend or transitioncancel (and you are guaranteed to get exactly one of those).

(And, completely unrelated, but thank you so much for all your work on PouchDB! I've been poring over PouchDB code recently for a PouchDB-based hobby project I'm working on and really appreciate all you've done. Thank you!)

[nolanlawson]

(No worries, glad to know Pouch is useful to you. 😃)

Probably the best way to start this conversation would be to file a bug on Edge; since you have a fiddle, you can try our fancy new thing by tweeting to #edgebug, or just file an issue at Edge issues. I agree it sounds like our implementation deviates from the spec (especially given "start time is the time of the style change event plus the matching transition delay" from this page), so pointing to the spec would strengthen the case.

[birtles]

I'm pretty sure the Edge behavior predates the spec so it's not an implementation bug per-se. It's really just a question of what we want to spec. For the use case I mentioned above, I think we have two options:

1. Make transitionstart ignore delay and update Edge.
2. Spec transitionstart (includes delay) and transitionfire (does not include delay).

Doing (1) depends on Edge being prepared to update. If someone from Edge were to say, "We have people using this in the wild, we can't possibly change that" then that would make the decision easier, but I suspect that's not the case.

Even so, (2) is still appealing since making transitionstart reflect the transition delay is consistent with animationstart. We'd need to bikeshed the new event name though, transitionfire? transitiondispatch? transitioncreate? transition?

Is anyone from Edge able to comment on (a) why transitionstart was added in the first place (were there other use cases where including the delay makes sense?), and (b) if changing this is feasible?

I think I'm starting to I lean towards just doing (2) anyway for consistency with animation events.

[birtles]

I should also mention that transitionstart goes back to IE10.

[ChumpChief]

I also find (2) more appealing for the reasons you mention, plus would facilitate distinguishing delay from active phase. Maybe transitionrun, since it would map to when it is added to the set of running transitions, leaving transitionstart matching the start time?

[birtles]

I've added transitionrun and made transitionstart reflect the delay (i.e. match IE10/Edge behavior).

[nolanlawson]

Sounds like a good compromise. Thanks for being flexible! :)