[csswg-drafts] [css-transitions] Firing an animation whose start value matches the end of a transition does not clear the transition

birtles has just created a new issue for 
https://github.com/w3c/csswg-drafts:

== [css-transitions] Firing an animation whose start value matches the
 end of a transition does not clear the transition ==
See: [Mozilla bug 
119252](https://bugzilla.mozilla.org/show_bug.cgi?id=1192592)
Test case: 
https://bug1192592.bmoattachments.org/attachment.cgi?id=8645410

In this test case, clicking the box alternatively triggers a CSS 
animation then a CSS transition that animates from the end point of 
the animation back to the original value.

The sequence is something like this:

1. First click: Apply `bounce` animation with forwards fill mode. 
Final value of 'width' is 250px.
2. Second click: Remove animation. 'width' transitions from 250px back
 to 200px. At this point we have a completed transition (250px → 
200px).
3. Third click: Apply `bounce` animation again. Final value of 'width'
 is 250px.
4. Fourth click: Remove animation. At this point we determine if we 
should trigger a new animation based on the following [spec 
text](https://drafts.csswg.org/css-transitions/#starting):

> 1. If all of the following are true:
> * the element does not have a running transition for the property,

→ true
> * the before-change style is different from and can be interpolated 
with the after-change style for that property,

before-change style: `width: 250px`
after-change style: `width: 200px`
→ true
> * the element does not have a completed transition for the property 
or the end value of the completed transition is different from the 
after-change style for the property,

end value of the completed transition: `width: 200px`
after-change style: `width: 200px`
→ false
> * there is a matching transition-property value, and

→ true
> * the combined duration is greater than 0s, 

→ true

So because one of the conditions evaluated to false, we don't fire a 
transition the second time around.


But perhaps the issue is that we should have removed the completed 
transition back in step 3 when we applied the animation? In that case 
we consider this same condition and the next:

> 1. If all of the following are true:
> * the element does not have a running transition for the property,

→ true
> * the before-change style is different from and can be interpolated 
with the after-change style for that property,

before-change style: `width: 200px` (end point of transition)
after-change style: `width: 200px` (start of animation)
→ false
> * the element does not have a completed transition for the property 
or the end value of the completed transition is different from the 
after-change style for the property,

end value of the completed transition: `width: 200px`
after-change style: `width: 200px` (start of animation)
→ false
> * there is a matching transition-property value, and

→ true
> * the combined duration is greater than 0s, 

→ true
> 2. Otherwise, if the element has a completed transition for the 
property and the end value of the completed transition is different 
from the after-change style for the property, then implementations 
must remove the completed transition from the set of completed 
transitions.
end value of the completed transition: 200px
after-change style: 200px
→ false

Perhaps we need special handling for if an animation is triggered that
 contains the transition property? E.g., in step 3 if we have a 
completed transition, and the style change event includes creating a 
new animation that references the transition property, cancel the 
completed transition. I suppose that won't work if the @keyframes rule
 is updated later, however.

Or should the before-style change not include animations in the first 
place meaning we don't trigger a transition in step 2? That seems to 
be what Edge / Chrome do.

CC: @dbaron

Please view or discuss this issue at 
https://github.com/w3c/csswg-drafts/issues/679 using your GitHub 
account

Received on Friday, 4 November 2016 07:04:23 UTC