I animate an element using the translateX() property, together with a transition-timing-function. But it seems that the timing function is not applied? When i use transition of left: xx instead it works.
But as translate uses the GPU its much faster, so i would like to use this instead. Any ideas why is that?
The problem is chrome.
It seems to be not implemented for translate in chrome.
Check the jsfiddle here in the comments.
works in safari, but not chrome.
Related
I have an element with a -webkit-filter: blur(10px); applied to it. I'm using a CSS animation to move the element up and down with it's translateY property. When the element is animating or transitioning the blur remains but the edges become hard. When the animation or transition ends the the edges become blurred again like they're suppose to. I made a demo that shows examples of the notes that follow it.
Demo: http://jsbin.com/bofahekuko/1/edit?html,css,output
I Tried Fixing it With:
adding -webkit-font-smoothing: subpixel-antialiased; to the animating element.
forcing hardware acceleration on the animating element and adding backface-visibility: hidden on the parent
Things of Note
Happens with both CSS transitions and animations
If you move the element up and down via the CSS top property the blur filter renders correctly.
Browser Testing
Bug appears in Google Chrome (running Version 50.0.2661.86 (64-bit)) as well as in Canary.
Both Firefox and Safari (iOS and Desktop) correctly render the blur filter during the animation.
I'd really like to be able to run the animation with the translateY transition property instead of the top property. If there really isn't a fix it'd still be interesting to know what exactly is going on here to cause the problem.
Thanks in advance for any help on this.
This is a problem that's probably caused by hardware accceleration - the GPU is just moving the original blurred content without updating its background.
To fix, don't use translate or use another trick to disable hardware acceleration (like simultaneously animating margin or padding)
I have a weird rendering glitch on a webpage in google chrome. I reproduced it under Mac Chrome, and Chrome under a parrallels virtual machine in windows.
It's supposed to be a simple draggable div. But, when you drag it around, it looks like this: http://imgur.com/VdY3Tv2
The situation is pretty unusual; it's a container div with a css transform matrix, containing an iframe, with a draggable div.
I created a demo. Just drag the div around: https://www.dropbox.com/s/cjq39w82mghuze2/bug.7z?dl=0
Any idea what causes this?
[edit]
I still have no idea. But: updating the transform matrix of the parent element (in my case, I was using fit.js, and call watching.trigger()) forces a redraw. So, that might be a useful workaround that helps people. :)
I found an actual fix that is not stupid and half-working like my earlier attempt.
iframe {
-webkit-backface-visibility: hidden; /* Chrome, Safari, Opera */
backface-visibility: hidden;
}
To clarify, to any iframe in which you have this happening, apply the above CSS.
No more glitches. Stupid, I have no idea why it worked, but I just tried random things, and then this worked. I'm guessing it enables some kind of different rendering flow that avoids this bug, whatever it is.
So i have this fiddle: http://jsfiddle.net/aA9Rm/1/ . It works just fine in firefox, but i have some issues with it in chrome, and i can't understand why. In firefox if i move the mouse after the hover in the workhover container it works fine, doesn't do anything, but in chrome if i try to click or move an inch, it starts to move (shake) and I don't want that.
I use 3D rotations, from CSS3,
-moz-transform: rotateY(-90deg);;
-webkit-transform:rotateY(-90deg);
transform:rotateY(-90deg);
Solutions anyone?
I think you encounter the same bug from this question :
CSS Flip Transition Between Two <div>'s
It looks like a chrome bug where the div you're trying to rotate is rotating a bit too much. I can fix your jsfiddle on Chrome by changing this CSS (see the webkit degree) :
.cube:hover{
-moz-transform: rotateY(-90deg);
-webkit-transform:rotateY(-89.9deg);
transform:rotateY(-90deg);
}
It's quite hacky but I never found any clean solution.
You can also use pointer-events: none; property in some way to make it works.
I'm building a simple pure-css 'card flip' animation, it has to work in IE10, but sadly what I've written doesn't.
jsFiddle demo here or sample html zip here
I can see that backside-visibility works in IE10 from their demo here so maybe I've just overlooked something stupid, maybe a fresh pair of eyes might help!
Thanks in advance!
Well some Microsoft IE devs saw my tweet and jumped in with a fix already!
Apparently IE10 does not support preserve-3d, and they whipped up this jsFiddle demonstration
Big thanks to #reybango and #sgalineau for the help - very much appreciated.
This seems to be a duplicate of CSS3 - 3D Flip Animation - IE10 transform-origin: preserve-3d workaround
The backside-visibility is working on IE10 when it is applied to the element itself (if applied to the parent, it will not work). You should combine it in the same transform property like this:
.back{
transform : perspective(1000px) rotateY(0deg);
}
.front{
transform : perspective(1000px) rotateY(180deg);
}
I only have the backface-visibility applied to the child element, and IE10 shows the backface anyway. Removing preserve-3d defeats one of the main visual features of 3d animation, so it's not really a viable workaround.
Unfortunately the demo referred to above by #reybango and #sgalineau changes the effect appearance from a 3d rotation to a simple 2d change in width, so it's not a viable workaround either.
Bottom line is that IE10 needs to be upgraded to support the CSS 3d animation spec as written.
(This is to comment on why microsoft's 360° turn example works.)
First take a look at the example itself, MS's workaround removed the preserve-3d transform-style property from initial code.
Turns out IE10 has no support for preserve-3d, and they suggest such workaround on msdn:
http://msdn.microsoft.com/en-us/library/ie/hh673529%28v=vs.85%29.aspx#the_ms_transform_style_property
With transform-style set to default 'flat' value, child elements will inherit parent rotation. Thus both card front/back are rotated to 360° (= 0°), the trick here is that back side will appear on top, because it comes later in DOM.
Just to make this a bit more apparent, I added opacity:0.5 to back-side for both examples, now you can see what's really going on:
http://jsfiddle.net/7FeEz/12/
http://jsfiddle.net/ax2Mc/71/
So the MS way will work in some scenarios, but not all without real support for preserve-3d
Here is my solution. http://jsfiddle.net/UwUry/531/
I tried on IE 11 and Chrome. It worked like a flip box.
I have been working with changing the background colour of an element using css3 animations. However it does not work in Chrome. I have attached a jsFiddle example of the code I am using. It works in Firefox, but not in Chrome and despite my best efforts I have been unable to work out what the problem is.
In chrome is seems to ignore the reference to background-color only. If I move the item or apply any other effect to the element it works fine.
http://jsfiddle.net/qWKEs/6/
Thanks in advance.
This is a bug in chrome. Should be fixed in version 18 as per http://code.google.com/p/chromium/issues/detail?id=101245
I had this same issue using the background property in Chrome with CSS3.
However the version of Chrome is 21.0.1180.83 (up to date as of 8/24/12) so the problem still exists.
I resolved it by specifying background-color instead and that works fine.
Interestingly enough the W3C says it's only supported in version 1.