Re: Transition events (and transforms) community expectations research

Hi Rachel,

Thanks for doing this research. I've left a few comments inline and then at
the end.

On Thu, Jun 29, 2017 at 1:18 AM, Rachel Nabors <Rachel.Nabors@microsoft.com>
wrote:
...

> *Caveats*
>
> This conversation originally started around transitionend, but since the
> original Transitions spec
> <https://drafts.csswg.org/css-transitions/#event-transitionevent>,
> transitionrun, transitionstart, and transitioncancel have been added and
> are supported by FireFox and Edge (except for transitionrun). Some of the
> developers I interviewed expressed what sounded like a yearning for events
> like these, but weren't aware of their existence.
>

As far as I can tell, transitioncancel doesn't appear to be implemented in
Edge (using this test: https://jsfiddle.net/r7LoLjcv/ in EdgeHTML 15.15063;
furthermore the corresponding UserVoice entry
<https://wpdev.uservoice.com/forums/257854-microsoft-edge-developer/suggestions/15939898>
is still open).

...

> *This jives with what I've heard from others.* The author of anime.js
> chose to work with JavaScript only after finding CSS transition events too
> unreliable:
>
>
>
> "I always had mixed results using transitionend, it wasn't super reliable
> from what I remember. That's one of the reason that motivated me to make a
> JS animation library with a more reliable 'complete' callback :) "
>

This is solved by transitioncancel.


> Matias Niemela who works on Angular's animation features at Google says,
> "It doesn't fire if a style changes, but no visual effect… This problem
> makes using transitions within a framework totally horrible because there's
> no way to validate if the element actually kicked off an animation."
>

This is solved by transitionrun.


> Also "In some browsers, if you animate something like border then it will
> fire four events (top, left, right, bottom). So having a framework
> understand and operate on this glitch is annoying."
>

All browsers should fire events for all longhands if their computed value
changes. There shouldn't be any browser inconsistencies here other than
discrepancies about what constitutes a change in computed value (discussed
below).


> Ben Alpert who has worked on React's CSSTransitionGroup says, "Ultimately
> we gave up and switched to a timer-based approach where you manually
> specify the time in ms when using the component, and we ignore the CSS
> events if that's present."
>

This is exactly why we specced and implemented transitionrun and
transitioncancel.


> (Using timers is a major no-no, as it removes control of animation
> timelines from the browser, makes chaining more fragile.) "I like
> transitionend to fire for all of those cases because it's pretty
> confusing when degenerate cases have different behavior than all
> non-degenerate cases… I would have liked some event that is guaranteed to
> fire when a certain transition is done (and probably one that fires
> immediately if no transition happens) -- though I understand that there's
> currently no way (AFAIK) to identify a specific transition from JS. Even a
> way to globally wait for all transitions on an element (if any) to finish
> would be helpful and the closest thing to our original needs."
>

This is Web Animations' getAnimations() method to a 't' (although it is yet
to ship to release in any browser since we still have some spec work to do
there).

Overall I think the current behavior where a transition fires if the
computed value changes is still the most practical option. To fire events
when the computed value does *not* change would mean preserving specified
values when comparing before and after styles which would be very
burdensome for implementations. To *not* fire events when the computed
*does* change would just introduce the kind of inconsistencies library
authors seem concerned about.

Where browsers differ, presumably they have different notions of what
constitutes a change in computed value. If specs are unclear about computed
values then obviously we need to fix those, otherwise these would appear to
be fairly straightforward browser bugs. Specific test results where
behavior differs would be most welcome.

That said, transitionrun and transitioncancel go a long way towards
allowing library authors to cope with browser differences since authors can
detect when a transition has been created and hence when they can expect an
end event.

At this stage I think the most useful step would be to encourage browsers
to implement these extra events. We have quite a few tests for this in
Gecko but many of them rely on the Web Animations API. I'll see if I can
tidy up a subset that don't require that API and submit them to
web-platform-tests.

Best regards,

Brian