New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
birtles opened this Issue Nov 4, 2016 · 2 comments

Comments

Projects
None yet
2 participants
@birtles
Contributor

birtles commented Nov 4, 2016

See: Mozilla bug 119252
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:
  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

  1. 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

@birtles

This comment has been minimized.

Show comment
Hide comment
@birtles

birtles Nov 4, 2016

Contributor

Hmm, no the spec specifically mentions that the before-change style includes the result of animations:

"Otherwise, define the before-change style as the computed values of all properties on the element as of the previous style change event, except with any styles derived from declarative animations such as CSS Transitions, CSS Animations ([CSS3-ANIMATIONS]), and SMIL Animations ([SMIL-ANIMATION], [SVG11]) updated to the current time."[1]

[1] https://drafts.csswg.org/css-transitions/#before-change-style

Contributor

birtles commented Nov 4, 2016

Hmm, no the spec specifically mentions that the before-change style includes the result of animations:

"Otherwise, define the before-change style as the computed values of all properties on the element as of the previous style change event, except with any styles derived from declarative animations such as CSS Transitions, CSS Animations ([CSS3-ANIMATIONS]), and SMIL Animations ([SMIL-ANIMATION], [SVG11]) updated to the current time."[1]

[1] https://drafts.csswg.org/css-transitions/#before-change-style

@dbaron

This comment has been minimized.

Show comment
Hide comment
@dbaron

dbaron Jan 7, 2017

Member

After looking at this again, I'm starting to think that the spec is actually OK on this right now, since, per the spec, each movement of the CSS Animation constitutes its own style change event, so the completed transition gets removed the moment the animation animates the value away from 200px (i.e., shortly after step (3)).

Member

dbaron commented Jan 7, 2017

After looking at this again, I'm starting to think that the spec is actually OK on this right now, since, per the spec, each movement of the CSS Animation constitutes its own style change event, so the completed transition gets removed the moment the animation animates the value away from 200px (i.e., shortly after step (3)).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment