Bug 161535 - Implement the transitioncancel event
Summary: Implement the transitioncancel event
Status: NEW
Alias: None
Product: WebKit
Classification: Unclassified
Component: Animations (show other bugs)
Version: WebKit Nightly Build
Hardware: All All
: P2 Normal
Assignee: Nobody
URL: https://drafts.csswg.org/css-transiti...
Keywords: W3CTest
Depends on:
Blocks:
 
Reported: 2016-09-02 09:51 PDT by Chris Rebert
Modified: 2016-09-02 15:38 PDT (History)
2 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Chris Rebert 2016-09-02 09:51:04 PDT
Specification: https://drafts.csswg.org/css-transitions-2/#eventdef-transitionevent-transitioncancel

Steps to reproduce the problem:
1. Open the CSSWG testcase https://github.com/w3c/csswg-test/blob/master/css-transitions-2/transitioncancel-001.html in Safari.

What is the expected behavior?
The test should pass.

What went wrong?
The test failed, indicating that Safari is not firing the transitioncancel event when a transition is canceled.
(In this case, the cancellation is due to the element being made display:none; while the transition was in progress.)


Without transitioncancel, scripts which are waiting for the end (whether normal or canceled early) of a CSS transition have to resort
to using setTimeout (or similar) to ensure that their callbacks still get called even if the transition gets canceled.
This extra complexity is annoying to authors, and frameworks often include such setTimeout-based workarounds in practice, for example:
* https://github.com/twbs/bootstrap/blob/c56219d223af5145c171defb9fa1426e1dd022f3/js/transition.js#L36
* https://github.com/Semantic-Org/Semantic-UI/blob/f725b162e70896e38257965424ac7f9af486b927/src/definitions/modules/transition.js#L441
Such extra setTimeout()s also presumably have a negative impact on performance.