I am working with keyframe animations in CSS, and I want to be able to specify different timing functions for each property I'm animating. For instance, during a given keyframe, I'd like to animate opacity from 0 to 1 with an ease-in timing function, and top from 0 to 100 with a linear timing function.
This is possible with CSS transitions, by doing something like the below. (Unfortunately I need keyframed animations for other reasons.)
-webkit-transition-property: opacity, top;
-webkit-timing-function: ease-in, linear;
Also, I noticed (at this link) that the specification for the animation-timing-function property accepts a comma delimited list. However, I don't see any way to specify a corresponding list of properties or any documentation on what the purpose of a list of timing functions is. Does anyone know if what I'm trying to do is possible?
I find it easier to just use comma separated shorthands:
img {
-webkit-animation:
updown 2s ease-in infinite,
rotate 1s ease-out infinite;
}
http://jsfiddle.net/desz9/
Related
We have excellent mixins for opacity and transitions in compass, but how can I do a transition on opacity?
#include single-transition(opacity, 1s);
Above line creates a transition on opacity, but not on -moz-opacity, -khtml-opacity, let alone the weird IE syntaxes...
I think the following code (but also the code you posted) creates the animation with all the required prefixes.
#include transition(opacity, 1s ease-out);
Where 1s is any amount of seconds (2s, 0.5s) and ease-out is any kind of easing animation (could be just linear if no parameter).
Sample CSS:
background-image: -moz-linear-gradient(90deg, #e8f0ff, #ffffff);
background-image: -ms-linear-gradient(90deg, #e8f0ff, #ffffff);
background-image: -o-linear-gradient(90deg, #e8f0ff, #ffffff);
background-image: -webkit-linear-gradient(90deg, #e8f0ff, #ffffff);
background-image: linear-gradient(90deg, #e8f0ff, #ffffff);
This used to result in a linear gradient going from #e8f0ff at the bottom, to #fff at the top.
Post-Firefox 16 (released a few days ago), the gradient now goes from #e8f0ff at the left, to #fff at the right.
When I remove the vendor-specific CSS and leave just:
background-image: linear-gradient(90deg, #e8f0ff, #ffffff);
Nothing happens. But when I delete that line and leave just the vendor-specific styles:
background-image: -moz-linear-gradient(90deg, #e8f0ff, #ffffff);
background-image: -ms-linear-gradient(90deg, #e8f0ff, #ffffff);
background-image: -o-linear-gradient(90deg, #e8f0ff, #ffffff);
background-image: -webkit-linear-gradient(90deg, #e8f0ff, #ffffff);
It corrects the problem.
So what's happening here that's new in FF16? Are the Xdeg values starting from a new direction, are they being added together only in certain situations? I can't figure out why it would do 180deg with both or with only general, but only 90deg if it's only vendor.
The question is, what are the specifics of this new behavior from Firefox, and what's the broadest, most standards-compliant solution for websites that now have their gradients going the wrong way in FF16?
The standard dictates that angles are measured clockwise starting from 0° = upward.
using angles
For the purpose of this argument, ‘0deg’ points upward, and positive angles represent clockwise rotation, so ‘90deg’ point [sic] toward
the right.
-moz-linear-gradient, on the other hand, uses polar coordinates (emphasis mine):
A last semantic curiosity still exists between the prefixed variants and the unprefixed proposal. Following the initial Apple proposal, the prefixed variants of the syntax all uses the an <angle> defined like polar angles, that is with 0deg representing the East. To be coherent with the rest of CSS, the specification defines an angle with 0deg representing the North. To prevent sites using prefixed version of the property to get suddenly broken, even when adapting to the otherwise forward-compatible final syntax, they keep the original angle definition (0deg = East). They will switch to the correct spec when unprefixing the property. Also, as they aren't incompatible, Gecko supports, prefixed, both the syntax with the to keyword and without. Here again, the syntax without the keyword will be dropped when unprefixing.
A simple hack can be to use the keyword bottom instead of degrees.
A number of blogs have expressed the performance gain in 'tricking' the GPU to think that an element is 3D by using transform: translateZ(0) to speed up animations and transitions. I was wondering if there are implications to using this transform in the following manner:
* {
-webkit-transform: translateZ(0);
-moz-transform: translateZ(0);
-ms-transform: translateZ(0);
-o-transform: translateZ(0);
transform: translateZ(0);
}
CSS transformations create a new stacking context and containing block, as described in the spec. In plain English, this means that fixed position elements with a transformation applied to them will act more like absolutely positioned elements, and z-index values are likely to get screwed with.
If you take a look at this demo, you'll see what I mean. The second div has a transformation applied to it, meaning that it creates a new stacking context, and the pseudo elements are stacked on top rather than below.
So basically, don't do that. Apply a 3D transformation only when you need the optimization. -webkit-font-smoothing: antialiased; is another way to tap into 3D acceleration without creating these problems, but it only works in Safari.
If you want implications, in some scenarios Google Chrome performance is horrible with hardware acceleration enabled. Oddly enough, changing the "trick" to -webkit-transform: rotateZ(360deg); worked just fine.
I don't believe we ever figured out why.
It forces the browser to use hardware acceleration to access the device’s graphical processing unit (GPU) to make pixels fly. Web applications, on the other hand, run in the context of the browser, which lets the software do most (if not all) of the rendering, resulting in less horsepower for transitions. But the Web has been catching up, and most browser vendors now provide graphical hardware acceleration by means of particular CSS rules.
Using -webkit-transform: translate3d(0,0,0); will kick the GPU into action for the CSS transitions, making them smoother (higher FPS).
Note: translate3d(0,0,0) does nothing in terms of what you see. It moves the object by 0px in x,y and z axis. It's only a technique to force the hardware acceleration.
Good read here: http://www.smashingmagazine.com/2012/06/21/play-with-hardware-accelerated-css/
I can attest to the fact that -webkit-transform: translate3d(0, 0, 0); will mess with the new position: -webkit-sticky; property. With a left drawer navigation pattern that I was working on, the hardware acceleration I wanted with the transform property was messing with the fixed positioning of my top nav bar. I turned off the transform and the positioning worked fine.
Luckily, I seem to have had hardware acceleration on already, because I had -webkit-font-smoothing: antialiased on the html element. I was testing this behavior in iOS7 and Android.
On mobile devices sending everything to the GPU will cause a memory overload and crash the application. I encountered this on an iPad app in Cordova. Best to only send the required items to the GPU, the divs that you're specifically moving around.
Better yet, use the 3d transitions transforms to do the animations like translateX(50px) as opposed to left:50px;
So I've got some native elements (divs) with various effects applied to them (border-radius, box-shadow and transform: scale()). When I animate them, two weird things happen:
Even though I'm not trying to animate the scale, if I don't put the scale in the animation, it is ignored.
When I put the scale in the animation, Webkit blurs the elements
See the example here: http://jsfiddle.net/trolleymusic/RHeCL/ - the buttons at the bottom will trigger the issues.
The first issue happens in Firefox too, so I'm guessing that it's because that's how the animation spec is supposed to work. Not what I wanted, but ok, I'll live with it.
The second issue is just weird. I know it's to do with 3d transform because if I (just for testing purposes) declare -webkit-perspective or -webkit-transform-style: preserve-3d; on the circle elements, it causes the blur issue as well. My confusion is that I'm not trying to transform the z index as all, and I have also tried the animations using purely translateY instead of translate.
It happens in Chrome (18), Chrome Canary (20) and Safari (5.1.2 & 5.1.4).
So, am I right in what I think is happening? And how can I avoid the blurriness?
Worst-case scenario: I can just use different sizes for the elements instead of scaling them, that's not really a problem - but I thought this would be a more elegant solution and now this issue has cropped up.
Refer to this answer as to why it's blurring the element: https://stackoverflow.com/a/4847445/814647
Summary of the above: WebKit is taking the original size/CSS before animating, and treating it as an image, THEN scales it up, producing the blurriness.
Solution: Make initial size the largest scale you're going to, and start it initially with a lower scale (so in your case you'd want to up the size by 5, and set the initial scale to 0.2)
UPDATE
The reason it ignores the current scale from what I understand is because you're not specifically setting JUST the translate (I'm looking up the CSS for it now). When you run -webkit-animation, it's resetting all your current transforms (scale), so you need to make sure that you have your scales in there. I'm looking up the css to change so it only changes just the position:
The best way I found is to wait the animation is complete, then apply the transforms directly to the element and remove the animation class. Something like this works for me, producing no glitches:
$m.bindOnce($m('win-text'), 'webkitAnimationEnd', function(){ //avoid blurred problem with animating scale property in webkit
$m('win-text').style.webkitTransform = 'scale(1.5) translateY(-60px)';
$m.removeClass($m('win-text'), 'final');
});
I'm using a different library than jQuery, but you get the idea.
I've noticed that the more I use certain CSS3 elements (namely box-shadow and text-shadow) the more scroll lag exists on a page. I notice the problem on both FF4 and Chrome 10. Is there any good way to measure this or reduce it? I want good performance, but I also want to be able to use the shadows to create dimensionality between the various elements.
Thanks!
I've found the two biggest offenders (as far as performance goes) are the blur amount of your shadows and whether you're using any alphas (rgba, hsl, etc).
Hardware acceleration is key to using any of the css3 goodies and maintaining acceptable performance. Webkit (not sure about FF4) won't even use the GPU unless you specifically ask for a three-dimensional operation. You can kick in the GPU for any element by simply applying a 0-pixel 3d transform:
-webkit-transform: translate3d(0,0,0);
/* OR */
-webkit-transform: translateZ(0);
Paul Irish has a great talk on css3 performance and using webkits dev flags to debug GPU rendering.
From terminal (OS X), you can launch Safari with the GPU rendering debug flag with this:
CA_COLOR_OPAQUE=1 /Applications/Safari.app/Contents/MacOS/Safari
This will show you (in translucent red) which DOM regions are being rendered on the GPU and which ones are rendered by the CPU like this.