On my website I have this example of "blurry/bold/glitchy" text that appears after css transition occurs on translateY property.
See screenshot (top: how it should be / bottom: how it actually looks)
Here it is live (see as you scroll down): http://louisamiot.com/project/this-is-why
This definitely sounds like a text rendering issue on Webkit because some characters appear bolder than other and everything is fixed when you resize the windows.
I tried several fixes such as -webkit-font-smoothing: subpixel-antialiased; and all the common CSS tricks such as translate3D translateZ(0) scale(1.0) and backface-visibility: hidden; but none of them worked.
Any idea ? :)
Thanks a lot to the community.
I just build this website : http://rcmm.minnie.mico.dk/
And on the front page i have a slideshow (bad UX - I know). If you click one of the small square icons in the bottom right corner the slider will animate.
This works great, except in chrome for mac. Every time the slider animates, all the elements that are positioned absolute will do a tiny pixel-jump. The animations on the slider however is using transform: translate() to do the animation. js is only swapping classes - no actualt animating - thats all handled by css.
Does anyone know why this is, and if there is a possible fix for this?
Any help would be much appreciated.
Simply add -webkit-backface-visibility: hidden; to the <body> and the jumping should stop.
Any time you have minor glitches when using CSS Transforms, backface-visibility: hidden will straighten things out. It typically has to do with how the browser will handle hardware acceleration.
From CSS3 Animations: the Hiccups and Bugs You'll Want to Avoid:
The reason behind this phenomenon is unclear, but the fix is pretty simple. Simply adding the -webkit-backface-visibility: hidden; rule to your CSS should help prevent the problem. Apply it to the container of the element, like so:
.container {
-webkit-backface-visibility: hidden;
}
It boils down to another hardware acceleration problem - using this property simply kicks the acceleration into gear. You could also use things like -webkit-perspective: 1000; or other 3D properties.
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 have an element that is positioned absolutely above another. The thing is the background element has a little JS to rotate on the Y axis depending on the mouse's movement. Unfortunately, I am seeing an issue in Safari that doesn't appear in Firefox or Chrome.
http://jsfiddle.net/cehzd/2/
The background element cuts up through the foreground one, and I'd like to know if there is anything to prevent this, or have it behave like Firefox.
Edit: Updated example to include background image (gradient) which is more exact to what I see in my site. This bug does show up on both Windows and Mac (unlike previous example, sans background image, which was only on Windows)
There's definitely a bug, but I had to change your JSFiddle quite a bit. (Did you strip too much from your actual code?). I was able to recreate your issue by using -webkit-transform-style: preserve-3d; while not using it (or making it flat) fixes the "cut" in my code.
Take a look at this JSFiddle with my version of the bug (commented out) and the fix. Notice that applying that -webkit-transform-style: preserve-3d; does create your bug in Safari (Mac) while not in Chrome: http://jsfiddle.net/rgthree/cehzd/
Hopefully that helps.
I would simply add a transform: translateZ(100px); to the container in the foreground where 100px is the width of the blue container divided by 2 as its transform-origin is the default 50% 50%. It wouldn't have the same effect as transform: scale(...); as long as the outer wrapper doesn't have a transform-style of preserve-3d.
This question already has answers here:
Closed 10 years ago.
Possible Duplicate:
iphone webkit css animations cause flicker
For some reason, right before my animation of the webkit-transform property occurs, there is a slight flicker. Here is what I am doing:
CSS:
#element {
-webkit-transition: -webkit-transform 500ms;
}
JavaScript:
$("#element").css("-webkit-transform", "translateX(" + value + "px)");
Right before the transition takes place, there is a flicker. Any idea why this is, and how I could fix the problem?
Thanks!
Update: this only occurs in Safari. It does not happen in Chrome, although the animation does work.
The solution is mentioned here: iPhone WebKit CSS animations cause flicker.
For your element, you need to set
-webkit-backface-visibility: hidden;
The rule:
-webkit-backface-visibility: hidden;
will not work for sprites or image backgrounds.
body {-webkit-transform:translate3d(0,0,0);}
screws up backgrounds that are tiled.
I prefer to make a class called no-flick and do this:
.no-flick{-webkit-transform:translate3d(0,0,0);}
Add this css property to the element being flickered:
-webkit-transform-style: preserve-3d;
(And a big thanks to Nathan Hoad: http://nathanhoad.net/how-to-stop-css-animation-flicker-in-webkit)
For a more detailed explanation, check out this post:
http://www.viget.com/inspire/webkit-transform-kill-the-flash/
I would definitely avoid applying it to the entire body. The key is to make sure whatever specific element you plan on transforming in the future starts out rendered in 3d so the browsers doesn't have to switch in and out of rendering modes. Adding
-webkit-transform: translateZ(0)
(or either of the options already mentioned) to the animated element will accomplish this.
I had to use:
-webkit-perspective: 1000;
-webkit-backface-visibility: hidden;
on the element, or I would still get a flickr the first time a transition occurred after page load
I found that applying the -webkit-backface-visibility: hidden; to the translating element and -webkit-transform: translate3d(0,0,0); to all its children, the flicker then disappears
Trigger hardware accelerated rendering for the problematic element. I would advice to not do this on *, body or html tags for performance.
.problem{
-webkit-transform:translate3d(0,0,0);
}
Both of the above two answers work for me with a similar problem.
However, the body {-webkit-transform} approach causes all elements on the page to effectively be rendered in 3D. This isn't the worst thing, but it slightly changes the rendering of text and other CSS-styled elements.
It may be an effect you want. It may be useful if you're doing a lot of transform on your page. Otherwise, -webkit-backface-visibility:hidden on the element your transforming is the least invasive option.