Search code examples
csscss-animationsvendor-prefix

Are browser prefixes required for all version of animation keyframes

If a designer is using a fancy css animation and hopes to have functionality in older and newer browsers, we usually create a @keyframes and a @-webkit-keyframes section. Most of the examples I have seen use both non-prefixed and browser prefixed css under both keyframes, but is this necessary.

@keyframes coolEffect {
  -webkit-transform: some value;
  transform: some value;
  -webkit-animation-timing-function: some value;
  animation-timing-function: some value;
}
@-webkit-keyframes coolEffect {
  -webkit-transform: some value;
  transform: some value;
  -webkit-animation-timing-function: some value;
  animation-timing-function: some value;
}

Do we need non-prefixed values in the @-webkit-keyframes, since a browser using that would also use -webkit- prefixed css? And likewise since we are using @-webkit-keyframes, do we need to include -webkit- prefixed css in the main @keyframes? Would a simpler smaller version work equally as well?

@keyframes coolEffect {
  transform: some value;
  animation-timing-function: some value;
}
@-webkit-keyframes coolEffect {
  -webkit-transform: some value;
  -webkit-animation-timing-function: some value;
}

To clarify, I am not asking about what would work for my particular website, I am asking about functionality and whether or not code sample two would work the same as code sample one.

Thanks.

Solution

  • From my answer to this similar question:

    • WebKit-based browsers (including Opera 15 and later) still require the -webkit- prefix for animations today, and transforms are only unprefixed in recent versions of Chrome. You will need the prefix for both features.

    (Transforms were unprefixed in Chrome 36; animations were not unprefixed until Chrome 43. Both features were unprefixed simultaneously in Safari 9 so you never need to worry about prefixed/unprefixed overlap in Safari.)

    In a nutshell, while your two samples don't provide exactly the same functionality, there is no point including any unprefixed properties in @-webkit-keyframes as most WebKit browsers that depend on the prefixed at-rule are never going to need the unprefixed properties. Specifically, from our chat discussion:

    You can lose the unprefixed [animation-timing-function] declaration. @keyframes is in the same family as the animation-* properties and no browser in existence supports one unprefixed without the other

    As for transforms, only a very fringe few browsers simultaneously support unprefixed transforms and require prefixes on animations. These browsers do still support prefixed transforms, so similarly you can lose unprefixed transforms in @-webkit-keyframes

    Note the difference between "support" and "require"

    So, code sample two is all you need. It's over 40% smaller than code sample one, with no loss of functionality. 40% is a big deal. The only change I'd make is move the @-webkit-keyframes rule up:

    @-webkit-keyframes coolEffect {
  -webkit-transform: some value;
  -webkit-animation-timing-function: some value;
}
@keyframes coolEffect {
  transform: some value;
  animation-timing-function: some value;
}

    Readers may also be interested in my comments on Autoprefixer:

    I assume Autoprefixer sees that Chrome 36-42 supports unprefixed transforms but requires prefixed animations, so it puts transform in @-webkit-keyframes. I don't think that's a good approach. It needlessly doubles the transform declarations. All those versions of Chrome still understand -webkit-transform, so might as well stick to just that

    Autoprefixer is good for those who just don't want to have to worry about prefixes or doing all the research needed to really optimize their stylesheets

    If you want to optimize your stylesheet, you'll need to do quite a bit of research to find out where prefixes are needed and where they aren't, where unprefixed declarations are needed and where you can leave them out, etc. Prefixes are a pain either way ;)