<html>
<head>
<base href="https://bugs.webkit.org/" />
</head>
<body><table border="1" cellspacing="0" cellpadding="8">
<tr>
<th>Bug ID</th>
<td><a class="bz_bug_link
bz_status_NEW "
title="NEW - Implement the transitioncancel event"
href="https://bugs.webkit.org/show_bug.cgi?id=161535">161535</a>
</td>
</tr>
<tr>
<th>Summary</th>
<td>Implement the transitioncancel event
</td>
</tr>
<tr>
<th>Classification</th>
<td>Unclassified
</td>
</tr>
<tr>
<th>Product</th>
<td>WebKit
</td>
</tr>
<tr>
<th>Version</th>
<td>WebKit Nightly Build
</td>
</tr>
<tr>
<th>Hardware</th>
<td>All
</td>
</tr>
<tr>
<th>OS</th>
<td>All
</td>
</tr>
<tr>
<th>Status</th>
<td>NEW
</td>
</tr>
<tr>
<th>Severity</th>
<td>Normal
</td>
</tr>
<tr>
<th>Priority</th>
<td>P2
</td>
</tr>
<tr>
<th>Component</th>
<td>Animations
</td>
</tr>
<tr>
<th>Assignee</th>
<td>webkit-unassigned@lists.webkit.org
</td>
</tr>
<tr>
<th>Reporter</th>
<td>webkit@chrisrebert.com
</td>
</tr>
<tr>
<th>CC</th>
<td>dino@apple.com
</td>
</tr></table>
<p>
<div>
<pre>Specification: <a href="https://drafts.csswg.org/css-transitions-2/#eventdef-transitionevent-transitioncancel">https://drafts.csswg.org/css-transitions-2/#eventdef-transitionevent-transitioncancel</a>
Steps to reproduce the problem:
1. Open the CSSWG testcase <a href="https://github.com/w3c/csswg-test/blob/master/css-transitions-2/transitioncancel-001.html">https://github.com/w3c/csswg-test/blob/master/css-transitions-2/transitioncancel-001.html</a> 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:
* <a href="https://github.com/twbs/bootstrap/blob/c56219d223af5145c171defb9fa1426e1dd022f3/js/transition.js#L36">https://github.com/twbs/bootstrap/blob/c56219d223af5145c171defb9fa1426e1dd022f3/js/transition.js#L36</a>
* <a href="https://github.com/Semantic-Org/Semantic-UI/blob/f725b162e70896e38257965424ac7f9af486b927/src/definitions/modules/transition.js#L441">https://github.com/Semantic-Org/Semantic-UI/blob/f725b162e70896e38257965424ac7f9af486b927/src/definitions/modules/transition.js#L441</a>
Such extra setTimeout()s also presumably have a negative impact on performance.</pre>
</div>
</p>
<hr>
<span>You are receiving this mail because:</span>
<ul>
<li>You are the assignee for the bug.</li>
</ul>
</body>
</html>