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.
*** This bug has been marked as a duplicate of bug 183864 ***