Here's a reproduction of my issue (codepen because apparently stackoverflow's iframe affects the rendering somehow):
https://codepen.io/Ironimus/pen/GRjxpXZ
When using transform: translateZ and perspective inner elements' edges and text become blurry. It works very differently in different browsers, too. In case it also depends on screen or OS, here are a few screenshots with descriptions:
In Google Chrome transform: scale(2) is fine. Text and inner elements become blurry depending on the width of the element with perspective, and it follows very strange logic, when I set the width to 847px or higher it breaks, lower looks ok:
In Mozilla Firefox text becomes blurry if perspective/translateZ combination is used, inner elements are fine, transform: scale(2) is ok as well. width doesn't seem to affect anything:
In Safari everything is hella blurry whatever I do:
Why is it blurry at all and how do I make it right? Using transform: scale(2) for everything isn't a viable option. Are there maybe some rules I should follow to help browsers render 3D transforms with text right?
Supporting Safari isn't a priority but would still be nice
Have you tried adding a custom -webkit to the browser?
I am probably late with this answer but I recently encountered the same behavior when implementing a parallax design for a website.
This is a problem related to text being rendered as bitmaps in Safari, which are not re-rendered on transform: scale(x); but instead blown up in size.
It is possible to manually trigger a re-render of the text in some cases, however this is very finicky and there's no guaranteed way to make it work.
A more comprehensive answer to this was provided by Jack in this thread:
Transform scale() Safari bug when used on elements with border
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'm currently developing a web application using HTML5 and jQuery for iPad Safari. I'm running into a problem wherein large scroll areas cause the elements that are offscreen to appear after a delay when I scroll down to them.
What I mean by that is, if I have a row of images (or even a div with a gradient) that is offscreen, when I scroll down (or up) to it, the expected behavior is for the element to appear on screen as I am scrolling to it.
However, the element does not appear until I lift my finger off the screen and the scroller finishes all its animations.
This is causing a super noticeable problem for me, making the whole thing look choppy, although it is not. I'm guessing the iPad Safari is trying to do something to save memory. Is there a way in which I can prevent this choppy-ness from happening?
Additionally, what is iPad Safari actually trying to do?
You need to trick the browser to use hardware acceleration more effectively. You can do this with an empty three-dimensional transform:
-webkit-transform: translate3d(0, 0, 0)
Particularly, you'll need this on child elements that have a position:relative; declaration (or, just go all out and do it to all child elements).
It is not a guaranteed fix, but it is fairly successful most of the time.
Hat tip: iOS 5 Native Scrolling–Grins & Gotchas
I was using translate3d before. It produced unwanted results. Basically, it would chop off and not render elements that were offscreen, until I interacted with them. So, basically, in landscape orientation, half of my site that was offscreen was not being shown. This is a iPad web application, owing to which I was in a fix.
Applying translate3d to relatively positioned elements solved the problem for those elements, but other elements stopped rendering, once offscreen. The elements that I couldn't interact with (artwork) would never render again, unless I reloaded the page.
The complete solution:
*:not(html) {
-webkit-transform: translate3d(0, 0, 0);
}
Now, although this might not be the most "efficient" solution, it was the only one that works. Mobile Safari does not render the elements that are offscreen, or sometimes renders erratically, when using -webkit-overflow-scrolling: touch. Unless a translate3d is applied to all other elements that might go offscreen owing to that scroll, those elements will be chopped off after scrolling.
(This is the complete answer to my question. I had originally marked Colin Williams' answer as the correct answer, as it helped me get to the complete solution. A community member, #Slipp D. Thompson edited my question, after about 2.5 years of me having asked it, and told me I was abusing SO's Q & A format. He also told me to separately post this as the answer.
#Colin Williams, thank you! The answer and the article you linked out to gave me a lead to try something with CSS. So, thanks again, and hope this helps some other lost soul. This surely helped me big time!)
Targeting all elements but html: *:not(html)
caused problems on other elements in my case. It modified the stacking context, causing some z-index to break.
We should better try to target the right element and apply -webkit-transform: translate3d(0,0,0) to it only.
Sometimes the translate3D(0,0,0) doesn't work. We can use the following method, targeting the right element:
#keyframes redraw{
0% {opacity: 1;}
100% {opacity: .99;}
}
/* iOS redraw fix */
animation: redraw 1s linear infinite;
When the translate3d doesn't work, try to add perspective. It always works for me
transform: translate3d(0, 0, 0);
-webkit-transform: translate3d(0, 0, 0);
perspective: 1000;
-webkit-perspective: 1000;
Increase Your Site’s Performance with Hardware-Accelerated CSS
Adding -webkit-transform: translate3d(0,0,0) to an element statically doesn't work for me.
I apply this property dynamically. For example, when a page is scrolled, I set -webkit-transform: translate3d(0,0,0) on a element. Then after a short delay, I reset this property, that is, -webkit-transform: none
This approach seems to work.
Thank you, Colin Williams for pointing me in the right direction.
I had the same issue with iscroll 4.2.5 on iOS 7. The whole scroll element just disappear.
I've tried to add translate3d(0,0,0) as was suggested here. It has solved the problem, but it disabled the iscroll "snap" effect.
The solution came with giving the "position:relative; z-index:1000;display:block" CSS properties to the whole container that holds the scroll element and there isn't any need to give translate3d to child elements.
I had the same issue using an older version of Fancybox.
Upgrading to v3 will solve your problem or you can just add:
html, body {
-webkit-overflow-scrolling : touch !important;
overflow: auto !important;
height: 100% !important;
}
At time translate3d may not work. In those cases perspective can be used
transform: translate3d(0, 0, 0);
-webkit-transform: translate3d(0, 0, 0);
perspective: 1000;
-webkit-perspective: 1000;
I'm pretty darn sure I just solved this with:
overflow-y: auto;
(Presumably just overflow: auto; would work too depending on your needs.)
There are cases where a rotation is applied and/or a Z index is used.
Rotation: An existing declaration of -webkit-transform to rotate an element might not be enough to tackle the appearance problem as well (like -webkit-transform: rotate(-45deg)). In this case you can use -webkit-transform: translateZ(0px) rotateZ(-45deg) as a trick (mind the rotateZ).
Z index: Together with the rotation you might define a positive z-index property, like z-index: 42. The above steps described under "Rotation" were in my case enough to resolve the issue, even with the empty translateZ(0px). I suspect though that the Z index in this case may have caused the disappearing and reappearing in the first place. In any case the z-index: 42 property needs to be kept -- -webkit-transform: translateZ(42px) only is not enough.
This is a very common problem faced by developers and that is mainly due to Safari's property of not recreating elements defined as position : fixed.
So either change the position property or some hack needs to be applied as mentioned in other answers.
Issues with position fixed & scrolling on iOS
Change to position fixed on iOS Safari while scrolling
In my case (an iOS PhoneGap app), applying translate3d to relative child elements did not resolve the issue. My scrollable element didn't have a set height as it was absolutely positioned and I was defining the top and bottom positions.
Adding a min-height (of 100 pixels) fixed it for me.
I faced this problem in a Framework7 and Cordova project. I tried all the solutions above. They did not solve my problem.
In my case, I was using more than 10 CSS animations on the same page with infinite rotation (transform). I had to remove the animations. It is OK now with the lack of some visual features.
If the solutions in other answers do not help you, you may start eliminating some animations.
The -webkit-transform: translate3d(0, 0, 0); trick didn't work for me. In my case I had set a parent to:
/* Parent */
height: 100vh;
Changing that to
height: auto;
min-height: 100vh;
solved the issue in case someone else is facing the
same situation.
In my case, CSS did not fix the issue. I noticed the problem while using jQuery re-render a button.
$("#myButton").html("text")
Try this:
$("#myButton").html("<span>text</span>")
I just built out a website for a client, based on the Photoshop files they sent me, and they came back and told me that somehow the PSDs were 125% the size they were supposed to be, and that they need be to shrink everything to 80% of what it is now.
I figure I'm going to need to re-cut all the images, but I would rather not rewrite the CSS so I'm exploring alternatives.
Currently, all values are in pixels. I'm wondering if I should try to find a script that would take all the pixel values and multiply by .8, or if I should use a px to em converter and then set the base size in the html tag to 80%, or if there is better way to fix this problem.
Ugly css hack alert! :D
html {
zoom: 0.8; /* Old IE only */
-moz-transform: scale(0.8);
-webkit-transform: scale(0.8);
transform: scale(0.8);
}
Update
It appears latest Chrome and IE10 supports (and applies) both zoom and transform at the same time, scaling it twice, so I recommend only using zoom when testing old IE browsers.
You can re-size the page inside of an iframe that is at 80% width. You would need to remove the borders and turn scrolling of but it should work.
Tutorial here
How can I scale the content of an iframe?
I haven't tried it but it seems like it could possibly be sketchy as far a browser compatibility and bugs if you ask me. just thought i would pass it along
I'm seeing an issue where Chrome and other WebKit browsers massively blur any css-scaled content that also has translate3d applied.
Here's a JS Fiddle: http://jsfiddle.net/5f6Wg/. (View in Chrome.)
.test {
-webkit-transform: translate3d(0px, 100px, 0px);
}
.testInner
{
/*-webkit-transform: scale(1.2);*/
-webkit-transform: scale3d(1.2, 1.2, 1);
text-align: center;
}
<div class="test">
<div class="testInner">
This is blurry in Chrome/WebKit when translate3d and scale or scale3d are applied.
</div>
</div>
Are there any known workarounds for this? I get that in the simple example above, I could simply use translate rather than translate3d - the point here is to strip the code down to the bare essentials.
Webkit treats 3d transformed elements as textures instead of vectors in order to provide hardware 3d acceleration. The only solution to this would be to increase the size of the text and downscaling the element, in essence creating a higher res texture.
See here:
http://jsfiddle.net/SfKKv/
Note that antialiasing is still underpar (stems are lost) so I'm beefing up the text with a bit of text shadow.
I found that using:
-webkit-perspective: 1000;
on the container of your font or icon set kept things crisp for me after experiment with the issue on Android nexus 4.2 for sometime.
A css filter effect is a graphical operation that allows to manipulate the appearance of any HTML element. Since Chromium 19 these filters are GPU accelerates to make them super fast.
CSS3 introduces a bunch of standard filter effects, one of them is the blur fitler:
-webkit-filter: blur(radius);
The ‘radius’ parameter affects how many pixels on the screen blend into each other, so a larger value will create more blur. Zero of course leaves the image unchanged.
Set the radius to 0 will force browser to use GPU calculation and force it to keep your html element unchanged. It's like applying an "hard edges" effects.
So the best solution for me in order to fix this blurry effect was to add this simple line of code:
-webkit-filter: blur(0);
There is also a known bug that only affects retina screens. (See here: Why doesn't blur(0) remove all text blur in Webkit/Chrome on retina screens?). So in order to make it works also for retina, I recommend to add this second line:
-webkit-transform: translateZ(0);
Try this
...{
zoom:2;
-webkit-transform: scale(0.5);
transform: scale(0.5);
}
Or for a more exact approach you can call a javascript function to recalculate the transformation matrix by removing the decimal values of the matrix. see: https://stackoverflow.com/a/42256897/1834212
I came across this issue when using the isotope plugin (http://isotope.metafizzy.co/index.html) in combination with the zoom plugin (http://janne.aukia.com/zoomooz/). I built a jquery plugin to handle my case. I threw it up in a github repo in case anybody could benefit from it. - https://github.com/charleshimmer/jquery-hirestext.
I used javascript to move the text 1px top and then with 100ms after, back 1px down. It's almost unperceptive and solved the problem completely cross-browser.
body {
-webkit-font-smoothing: subpixel-antialiased;
}
or I think you could put that on a specific element, but I was having problems with one element affecting the whole site.
I think it is a problem with custom font-face fonts.
Webkit treats 3d transformed elements as textures instead of vectors
in order to provide hardware 3d acceleration.
This has nothing to do with it. You'll notice that your aliasing problem can be fixed with the addition of duration and direction information (e.g. 0.3 linear). Your having a mare trying to render everything at runtime:
Same for the above ^