CODEWITHSUNDEEP
google-chromeanimationcss
Grim...
Grim...

Reputation: 16953

CSS3 animation changes in latest version of Chrome?

Look at this JSFiddle: http://jsfiddle.net/Grimdotdotdot/URrLW/

In Firefox, it animates as expected - the red circle inside goes around and around, and the blue one on the outside rotates the other way at varying speeds and fades in and out.

This used to work fine in Chrome, but since the latest update to 21.0.1180.75 m the outer blue circle has stopped rotating.

Here is the CSS for the animation on Chrome:

@-webkit-keyframes spinPulse {
    0% { -webkit-transform:rotate(160deg); opacity:0; box-shadow:0 0 1px #2187e7; }
    40% { -webkit-transform:rotate(145deg); opacity:1;}
    80% { -webkit-transform:rotate(-320deg); opacity:0; }
    100% { -webkit-transform:rotate(-320deg); opacity:0; }
}

The problem is the opacity - if I remove it then the animation works fine (although it jumps at the end because you can see it): http://jsfiddle.net/Grimdotdotdot/BVXwR/

Is that a bug, or am I writing my CSS wrong?

Bonus points: How can I achieve the same animation in IE9?

Upvotes: 2

Views: 530

Answers (1)

Nick Treffiletti
Nick Treffiletti

Reputation: 11

So I have a similar situation. I am attempting to animate a number of divs in a given page and although they are being rendered in the source, they (and their child elements) are completely opaque in the latest Chrome. I believe (in my case) that I've nailed down the issue. Im using sass and the Bourbon mixin lib from the guys over at thoughtbot in a rails app but the situation is similar. Im not sure if this can really be considered a bug since the solution is really outlined in some places in the webkit spec - in fact as it stands it appears as though Chrome are the only ones that got this -right- and since it looks like theyre just beginning to support this (though safari does not?) it is mentioned. Regardless It is apparent when trying to animate a transform with an animation-fill-mode of both. I have verified that this works in an older version of Chromium and Safari. This is a recent issue that occurred in our application since the most recent Chrome update. Anyway, my sass code is something like this

.animation-tilefill {
  @include animation(tilefill 0.25s $ease-out-sine);
  @include animation-fill-mode(both); 
}
@mixin tilefill {
  0% {
    opacity: 0;
     // @include transform(scale(0.0)); // <= There's our issue
     // @include transform-origin(left top); 
  }
  80% {
     // @include transform(scale(1));
  }
  100% {
    opacity: 1;
  }
}
@-webkit-keyframes tilefill { @include tilefill; }
   @-moz-keyframes tilefill { @include tilefill; }
        @keyframes tilefill { @include tilefill; }

You'd have to know a little bourbon and sass to know what this is doing but for the needs of this answer, suffice it to say that its animating a scale transform as well as the opacity of the element. The problem with this code has nothing to do really with the transform itself but the 0.0 VALUE - the zero value being the key. If you look here: Safari CSS Reference you will see in the animation-fill-mode both description that:

"The animation’s initial keyframe is applied as soon as the animation style is applied to an element, and the animation’s final keyframe continues to apply after the final iteration of the animation completes. The initial keyframe only affects animations that have a nonzero value for -webkit-animation-delay."

The key part being The initial keyframe only affects animations that have a nonzero value for -webkit-animation-delay my fix was to change the values in the transform(scale()) to something non-negative such as:

  0% {
    opacity: 0;
     @include transform(scale(0.01)); // <= There's our issue
     @include transform-origin(left top); 
  }

Once that was changed, problem solved - hope this helps. I'd like to know what some people think of the support of this though :)

Upvotes: 1

Related Questions