I'm diddling with some css animations and I came to a small dilemma when it came to adding the vendor prefixes. I know that the "keyframes" property requires explicit defining with vendor prefixes just as much as some other CSS properties like "transform". However, what I've been wondering is whether I should include the vendor prefixes on both parts or the "keyframes" would be sufficient.
Here is an example of what I mean:
ex1:
#-webkit-keyframes animation_name {
0% {transform: rotateZ(0deg);}
100% {transform: rotateZ(180deg);}
}
ex2:
#-webkit-keyframes animation_name {
0% {-webkit-transform: rotateZ(0deg);}
100% {-webkit-transform: rotateZ(180deg);}
}
Which would be more correct?
Thanks in advance.
Example 2, as this is the style of output I would expect from an autoprefixer tool, for example: enter link description here
Related
I seem to have an issue with the webkit animations. I added an overlay spinner. This one shows fine on every browser (Mozilla, IE, Edge, Chrome). On Andriod and iPhone/iPad the animation is not fired. Am I missing something in my code?
In CSS I added following to the div of the element:
-webkit-animation-name:webkit-rotate-scale;
-webkit-animation-duration:0.75s;
-webkit-animation-direction:normal;
-webkit-animation-delay:0s;
-webkit-animation-iteration-count:infinite;
-webkit-animation-timing-function:linear;
-webkit-animation-play-state:running;
and
#-webkit-keyframes webkit-rotate-scale {
0% {-webkit-transform: rotate(0deg) scale(1);}
50% {-webkit-transform: rotate(180deg) scale(.5);}
100% {-webkit-transform: rotate(360deg) scale(1);}
}
Off course I added the standard (no webkit) alternatives also.
Can someone tell me what I'm missing?
The div where I am showing it in has display: inline-block.
Thanks in advance!
Kind regards,
Jerry
If i'm using #keyframes to perform a transform animation, how would I lay out my prefixes?
If i have the following:
#keyframes animation {
0% { transform:rotate(0deg); }
100% { transform:rotate(360deg); }
}
Do i then need to add all my transform prefixes to each keyframe declaration? EG:
#keyframes animation {
0% {
-webkit-transform:rotate(0deg);
-ms-transform:rotate(0deg);
transform:rotate(0deg);
}
100% {
-webkit-transform:rotate(360deg);
-ms-transform:rotate(360deg);
transform:rotate(360deg);
}
}
#-webkit-keyframes animation {
0% {
-webkit-transform:rotate(0deg);
-ms-transform:rotate(0deg);
transform:rotate(0deg);
}
100% {
-webkit-transform:rotate(360deg);
-ms-transform:rotate(360deg);
transform:rotate(360deg);
}
}
Does this work? If this the best way to do this or is there a shorthand / quicker way? I'd imagine this way will look bulky and horrible very quickly with even mildly complex animations.
In general, prefixes are a mess especially when it comes to CSS animations and transforms. I have a comprehensive guide to managing prefixes for these two features which you can find here.
What you have certainly works, but it's unnecessary:
Browsers other than IE aren't going to recognize the -ms-transform declaration anyway, and the versions of IE that support CSS animations out of the box also support unprefixed transform.
This means the -ms-transform simply isn't needed, at all. You should remove all instances of it. You only really need it outside of CSS animations where you want the transforms to work statically in IE9. See the link above for details.
Animations and transforms were unprefixed in WebKit only very recently. However, versions of WebKit that support #keyframes unprefixed also support transforms unprefixed. You can remove the -webkit-transform declarations from your #keyframes rule.
I wouldn't touch the unprefixed transform declarations in both rules. Transforms were unprefixed slightly earlier than animations, so some WebKit versions that require #-webkit-keyframes do support unprefixed transforms.
Also, the unprefixed rule should come last. This applies both to properties (like transform) and to at-rules (like #keyframes). Here's your CSS with the above optimizations:
#-webkit-keyframes animation {
0% {
-webkit-transform:rotate(0deg);
transform:rotate(0deg);
}
100% {
-webkit-transform:rotate(360deg);
transform:rotate(360deg);
}
}
#keyframes animation {
0% {
transform:rotate(0deg);
}
100% {
transform:rotate(360deg);
}
}
I'm totally stuck with this example of rotating span. http://jsfiddle.net/C94b8/1/ . What I want to do is rotate spin containing val from input but I just can't make it possible. Also tried changing span to display: inline-block. Didn't work either.
You need to set display to inline-block.
Also, Chrome doesn't support a un-prefixed transform yet. Instead, you need to use -webkit-transform. Firefox supports everything, so you don't have to worry there.
Also, you don't have to use 0% and 100%. If that's all you're using, you can use from and to.
One more thing: I think it's IE that doesn't support rotate. They want rotateZ. So I've changed it.
The finished product?
#-webkit-keyframes spin {
from {-webkit-transform: rotateZ(0deg);}
to {-webkit-transform: rotateZ(360deg);}
}
#keyframes spin {
from {transform: rotateZ(0deg);}
to {transform: rotateZ(360deg);}
}
header span {
display: inline-block;
/* All the rest of header span {} code goes here. I didn't copy it all. */
}
Are CSS prefixed keyframes stackable as long as they don't include any prefixed specific attributes in them?
Common
#-webkit-keyframes myAnimation{
to{ opacity:0; }
}
#-moz-keyframes myAnimation{
to{ opacity:0; }
}
#keyframes myAnimation{
to{ opacity:0; }
}
Stacked
#-webkit-keyframes myAnimation, #-moz-keyframes myAnimation, #keyframes myAnimation{
to{ opacity:0; }
}
Not natively in CSS but you can accomplish this by using a CSS preprocessor, for example LESS which supports the concept of "mixins" to remove some duplication.
More info can be found here, specifically the example from the article:
#-webkit-keyframes myAnimation {.mixi-frames;}
#-moz-keyframes myAnimation {.mixi-frames;}
.mixi-frames () {
opacity:0;
}
It wouldn't work unfortunately. If you group selectors, all of them have to be valid in order for any of them to be.
For instance, if you used your stacked example...
#-webkit-keyframes myAnimation, #-moz-keyframes myAnimation, #keyframes myAnimation{
to{ opacity:0; }
}
... on Firefox, it would read the webkit prefixed selector as invalid, which would make the rest of it, including the -moz- prefixed selector, also invalid.
Travis' preprocessor workaround in the other answer is probably the best way to write it cleanly as you'd like.
EDIT: This is misinformed, these can never be grouped as they are at-rules, not selectors. Same obviously goes for media queries (#media), #font-face, etc. Check out Boltclock's comment below.
I have a simple animation (only for Safari in this example):
h1 {
-webkit-animation: moveDown 1s ease-in-out;
}
#-webkit-keyframes moveDown {
0% {-webkit-transform: translateY(-20px); opacity: 0;}
100% {-webkit-transform: translateY(0px); opacity: 1;}
}
In the latest Safari (5.1.5) it works just fine.
But by accident I viewed the example in an older Safari (5.0.6) and saw nothing. The h1 was gone.
By kind of triggering eather by adding a none-rotate (opacity & animation works):
#-webkit-keyframes moveDown {
0% {-webkit-transform: translateY(-20px) rotate(0deg); opacity: 0;}
100% {-webkit-transform: translateY(0px) rotate(0deg); opacity: 1;}
}
or start at 1% (opacity doesn't work but animation):
#-webkit-keyframes moveUp{
1% {-webkit-transform: translateY(-20px); opacity: 0;}
100% {-webkit-transform: translateY(0px); opacity: 1;}
}
it worked again.
This now leads me to two serious questions:
Is there anything I did wrong in the first example?
Is there a known bug in older version of Safari which I should treat different?
Cause:
I don't mind if you can't see the animation in non-supporting browsers (it's just a nice add on) but it would be daring to not know when your animated element just doesn't show up anymore.
How could I be able to use animations in general as an add-on it without worrying?
If anybody askes for a fiddle: I tried recreating it. But here's another interesting thing: The exact same code will not have any effect in the old Safari in jsfiddle. Nor it animates or dissapears.
Edit:
I'm just seeing that the h1 is not dissapearing anymore with the original code (I can't reconstruct it) but doesn't do any animation eather. It just works with one of the described triggers.
JS-FIDDLE:
Here a working fiddle with the two examples.
I don't have an old version of Safari handy, but I recall playing with animations in older versions and encountered these types of bugs. I worked around them by putting the 'end state' in the selector, e.g. p {opacity: 1} http://jsfiddle.net/pkFaT/