Introduction
As you've seen in the previous chapters, CSS animations are indeed a real combo in the package of modern day web designing. They enable tons of possibilities in the 60fps workflow, which designers can experiment with in a number of ways.
However all this applies only if animations are supported out of the box in the browser. In this chapter we'll take a look at some vendor prefixing on the animation property which can make it support older browsers as well.
There aren't really any theories to discuss in this chapter, just some straightforward declarations and code examples, and therefore it won't take long to comprehend and conclude. So let's start!
The animation property
animation is the standard property to denote a CSS animation on modern browsers. Major vendors implement it and likewise are OK to go with it.
However some earlier browsers don't support animation as it is, but rather their own native implementations of it. The implementations are prefixed by a certain keyword and serve to support animations on older versions of browsers.
For example -webkit-animation deals with the older Google Chrome and Safari browsers, -o-animation deals with Opera whereas -moz-animation deals with Mozilla's Firefox.
This means that where a simple animation would look like the following in code,
div {
animation: myAnim 1s;
}a completely backwards-compatible code would involve all the prefixes, taking into account each set of vendors as shown below:
div {
-o-animation: myAnim 1s;
-moz-animation: myAnim 1s;
-webkit-animation: myAnim 1s;
animation: myAnim 1s;
}One thing to note over her is that the property animation is given the last on purpose, not just randomly!
animation at the beginning, instead of at the end, a later vendor prefixed property like -webkit-animation might override it, if it's supported. In this way we will be working with the native implementation of an animation in the browser rather than the standard one.
div {
animation: myAnim 1s;
-o-animation: myAnim 1s; /* this might override the animation property at the top */
-moz-animation: myAnim 1s; /* this might override the animation property at the top */
-webkit-animation: myAnim 1s; /* this might override the animation property at the top */
}The idea is that if the standard property is available then it should be the one in action, not the native ones. Thereby to be on the safe side and perhaps the latest side we write animation in the end.
The @keyframes rule
Just like we have tedious prefixing for animation, we have it for the @keyframes rule as well. The prefixing and the flow is the same: vendor-prefixed notations come before the standard notation.
So where a simple @keyframes rule would look as follows:
@keyframes myAnim {
from {opacity: 0}
to {opacity: 1}
}the one which is backwards compatible, as before, would involve prefixing:
/* For Opera */
@-o-keyframes myAnim {
from {opacity: 0}
to {opacity: 1}
}
/* For Mozilla Firefox */
@-moz-keyframes myAnim {
from {opacity: 0}
to {opacity: 1}
}
/* For Google Chrome and Safari */
@-webkit-keyframes myAnim {
from {opacity: 0}
to {opacity: 1}
}
/* The standard */
@keyframes myAnim {
from {opacity: 0}
to {opacity: 1}
}-o- and -moz-, and only stick with -webkit- - in this way they actually get their code snippets browser compatible but not that compatible as they could get them.And this concludes it all for CSS animations.
