Seems like there has been a recent update to Google Chrome that causes blurry text after doing a transform: scale(). Specifically I'm doing this:
#-webkit-keyframes bounceIn {
0% {
opacity: 0;
-webkit-transform: scale(.3);
}
50% {
opacity: 1;
-webkit-transform: scale(1.05);
}
70% {
-webkit-transform: scale(.9);
}
100% {
-webkit-transform: scale(1);
}
}
If you visit http://rourkery.com in Chrome, you should see the problem on the main text area. It didn't used to do this and it doesn't seem to effect other webkit browsers (like Safari). There were some other posts about people experiencing a similar issue with 3d transforms, but can't find anything about 2d transforms like this.
Any ideas would be appreciated, thanks!
I have had this problem a number of times and there seems to be 2 ways of fixing it (shown below). You can use either of these properties to fix the rendering, or both at the same time.
Backface visibility hidden fixes the problem as it simplifies the animation to just the front of the object, whereas the default state is the front and the back.
backface-visibility: hidden;
TranslateZ also works as it is a hack to add hardware acceleration to the animation.
transform: translateZ(0);
Both of these properties fix the problem that you are having but some people also like to add
-webkit-font-smoothing: subpixel-antialiased;
to their animated object. I find that it can change the rendering of a web font but feel free to experiment with that method too.
After trying everything else here with no luck, what finally fixed this issue for me was removing the will-change: transform; property. For some reason it caused horribly blurry looking scaling in Chrome, but not Firefox.
To improve the blurriness, esp. on Chrome, try doing this:
transform: perspective(1px) translateZ(0);
backface-visibility: hidden;
UPDATE: Perspective adds distance between the user and the z-plane, which technically scales the object, making the blurriness seem 'permanent'. The perspective(1px) above is like duck-tape because we're matching the blurriness we're trying to solve. You might have better luck with the css below:
transform: translateZ(0);
backface-visibility: hidden;
I found that adjusting the scale ratio helped slightly.
Using scale(1.048) over (1.05) seemed to generate a better approximation to a whole-pixel font size, reducing the sub-pixel blurring.
I also used translateZ(0) which seems to adjust Chrome's final rounding step in the transform animation. This is a plus for my onhover usage because it increases speed and reduces visual noise. For an onclick function however, I wouldn't use it because, the transformed font doesn't appear to be as crispy.
Instead of
transform: scale(1.5);
using
zoom : 150%;
fixes the text blurring problem in Chrome.
This must be a bug with Chrome (Version 56.0.2924.87), but the below fixes the bluriness for me when changing css properties in the console('.0'). I'll report it.
filter: blur(.0px)
Sunderls lead me to the answer. Except filter: scale does not exist, but filter: blur does.
Apply the next declarations to the elements that appear blurred (in my case they were inside a transformed element):
backface-visibility: hidden;
-webkit-filter: blur(0);
It almost worked perfectly. "Almost" because i'm using a transition and while in transition, elements don't look perfect, but once the transition is done, they do.
I found out, that the problem occures on relative transforms in any way. translateX(50%), scale(1.1) or what ever. providing absolute values always works (does not produce blurry text(ures)).
None of the solutions mentions here worked, and I think there is not solution, yet (using Chrome 62.0.3202.94 while I am writing this).
In my case transform: translateY(-50%) translateX(-50%) causes the blur (I want to center a dialog).
To reach a bit more "absolute" values, I had to set decimal values to transform: translateY(-50.09%) translateX(-50.09%).
NOTE
I am quite sure, that this values vary on different screen sizes. I just wanted to share my experiences, in case it helps someone.
In my case following code caused blurry font:
-webkit-transform: translate(-50%,-50%);
transform: translate(-50%,-50%);
and just adding zoom property fixed it for me. Play around with zoom, following worked for me:
zoom: 97%;
I have found a much better and clean solution:
.element{
transform:scale(0.5)
transform-origin: 100% 0;
}
or
.element{
transform:scale(0.5)
transform-origin: 0% 0;
}
Thanks to this post:
Preventing blurry rendering with transform: scale
I have this same problem. I fixed this using:
.element {
display: table
}
Another fix to try i just found for blurry transforms (translate3d, scaleX) on Chrome is to set the element as
"display: inline-table;".
It seems to force pixel rounding in some case (on the X axis).
I read subpixel positioning under Chrome was intended and devs won't fix it.
Try using zoom: 101%; for complex designs when you can't use a combination of zoom + scale.
2019 UpdateThe Chrome display bug is still unfixed and though no fault of the patrons, none of the suggestions offered in the entirety of this website help to resolve the issue. I can concur that I have tried every single one of them in vain: only 1 comes close and that's the css rule: filter:blur(0); which eliminates the shifting of a container by 1px but does not resolve the blurred display bug of the container itself and any content it may have.
Here's the reality: there literally is no fix to this problem so here is a work around for fluid websites
CASE
I'm currently developing a fluid website and have 3 divs, all centered with hover effects and sharing percentage values in both the width and position. The Chrome bug occurs on the center container which is set to left:50%; and transform:translateX(-50%); a common setting.
EXAMPLE: First the HTML...
<div id="box1" class="box">
Lorem Ipsum is simply dummy text of the printing and typesetting industry. Lorem Ipsum has been the industry"s standard dummy text ever since the 1500s, when an unknown printer took a galley of type and scrambled it to make a type specimen book.
</div>
<div id="box2" class="box">
Lorem Ipsum is simply dummy text of the printing and typesetting industry. Lorem Ipsum has been the industry"s standard dummy text ever since the 1500s, when an unknown printer took a galley of type and scrambled it to make a type specimen book.
</div>
<div id="box3" class="box">
Lorem Ipsum is simply dummy text of the printing and typesetting industry. Lorem Ipsum has been the industry"s standard dummy text ever since the 1500s, when an unknown printer took a galley of type and scrambled it to make a type specimen book.
</div>
Here's the CSS where the Chrome bug occurs...
*{margin:0; padding:0; border:0; outline:0; box-sizing:border-box; background:#505050;}
.box {position:absolute; border:1px solid #fff; border-radius:10px; width:26%; background:#8e1515; padding:25px; top:20px; font-size:12pt; color:#fff; overflow:hidden; text-align:center; transition:0.5s ease-in-out;}
.box:hover {background:#191616;}
.box:active {background:#191616;}
.box:focus {background:#191616;}
#box1 {left:5%;}
#box2 {left:50%; transform:translateX(-50%);} /* Bugged */
#box3 {right:5%;}
Here's the fixed css...
*{margin:0; padding:0; border:0; outline:0; box-sizing:border-box; background:#505050;}
.box {position:absolute; border:1px solid #fff; border-radius:10px; width:26%; background:#8e1515; padding:25px; top:20px; font-size:12pt; color:#fff; overflow:hidden; text-align:center; transition:0.5s ease-in-out;}
.box:hover {background:#191616;}
.box:active {background:#191616;}
.box:focus {background:#191616;}
#box1 {left:5%;}
#box2 {left:37%;} /* Fixed */
#box3 {right:5%;}
Bugged fiddle: https://jsfiddle.net/m9bgrunx/2/
Fixed fiddle: https://jsfiddle.net/uoc6e2dm/2/
As you can see a small amount of tweaking to the CSS should reduce or eliminate the requirement to use transform for positioning. This could also apply to fixed width websites as well as fluid.
It's important to add that this issue arises if the element which is being translated has a height with an odd number of pixels. So, if you have control over the height of the element, setting it to an even number will make the content appear crisp
None of above worked for me.
I had this animation for popups:
#keyframes pulse {
from {
transform: scale3d(1, 1, 1);
}
50% {
transform: scale3d(1.05, 1.05, 1.05);
}
to {
transform: scale3d(1, 1, 1);
}
}
In my case blurry effect was gone after applying this rule:
-webkit-perspective: 1000; even though it is marked as unused in Chrome inspector.
None of the above worked for me.
It worked when I added perspective
ie from
transform : translate3d(-10px,-20px,0) scale3d(0.7,0.7, 1)
i changed to
transform : perspective(1px) translate3d(-10px,-20px,0) scale3d(0.7,0.7, 1)
I used a combination of all answers and this is what worked for me in the end:
.modal .modal--transition {
display: inline-table;
transform: perspective(1px) scale(1) translateZ(0);
backface-visibility: hidden;
-webkit-font-smoothing: subpixel-antialiased;
}
My solution was:
display: initial;
Then it was crispy sharp
I was facing the blurry text issue on Chrome but not on Firefox when I used transform: translate(-50%,-50%).
Well, I really tried a lot of workarounds like:
transform: perspective(1px);
filter: blur(0);
transform: translateZ(0);
backface-visibility: hidden;
None of these worked to me.
Finally, I made the height and width of the element even. It resolved the issue for me!!!
Note: It might depend from use case to use case. But surely worth a try!
I have tried a lot of examples from these answers unfortunately nothing help for
Chrome Version 81.0.4044.138
I have added to transforming element instead
transform-origin: 50% 50%;
this one
transform-origin: 51% 51%;
it helps for me
This is what worked for me:
body { perspective: 1px; }
I fixed my case by adding:
transform: perspective(-1px)
I removed this from my code - transform-style: preserve-3d;
and added this- transform: perspective(1px) translateZ(0);
the blur went away!
FOR CHORME:
I´ve tried all suggestions here. But diden't work.
My college found a great solution, that works better:
You should NOT scale past 1.0
And include translateZ(0) in the hover but NOT in the none-hover/initial position.
Example:
a {
transition: all 500ms cubic-bezier(0.165, 0.840, 0.440, 1.000);
transform: scale(0.8, 0.8);
}
a:hover {
transform: translateZ(0)scale(1.0, 1.0);
}
In Chrome 74.0.3729.169, current as of 5-25-19, there doesn't seem to be any fix for blurring occurring at certain browser zoom levels caused by the transform. Even a simple TransformY(50px) will blur the element. This doesn't occur in current versions of Firefox, Edge or Safari, and it doesn't seem to occur at all zoom levels.
I have a div that has a small perspective shift on it to give a subtle 3D effect. The text in the div was blurring and I tried all the suggestions here to no avail.
Oddly, I found that setting 'filter: inherit;' on the text elements vastly improved the clarity. Though I can't understand why.
Here's my code in case it helps:
Html:
<div id="NavContainer">
<div id="Nav">
<label>Title</label>
<nav>
home
link1
link2
</nav>
</div>
</div>
Css:
#NavContainer {
position: absolute;
z-index: 1;
top: 0;
left: 20px;
right: 20px;
perspective: 80vw;
perspective-origin: top center;
}
#Nav {
text-align: right;
transform: rotateX(-5deg);
}
#Nav > nav > a,
#Nav > label {
display: inline-block;
filter: inherit;
}
#Nav > label {
float: left;
font-weight: bold;
}
For me the problem was that my elements were using transformStyle: preserve-3d. I realized that this wasn't actually needed for the app and removing it fixed the blurriness.
It will be difficult to solve with only css.
So I solved it with jquery.
This is my CSS.
.trY {
top: 50%;
transform: translateY(-50%);
}
.trX {
left: 50%;
transform: translateX(-50%);
}
.trXY {
top: 50%;
left: 50%;
transform: translate(-50%, -50%);
}
and this is my jquery.
function tr_init() {
$(".trY, .trX, .trXY").each(function () {
if ($(this).outerWidth() % 2 != 0) {
var fixed_width = Math.ceil($(this).outerWidth() / 2) * 2;
$(this).css("width", fixed_width);
}
if ($(this).outerHeight() % 2 != 0) {
var fixed_height = Math.ceil($(this).outerHeight() / 2) * 2;
$(this).css("height", fixed_height);
}
})}
Just to add to the fix craze, putting {border:1px solid #???} around the badly looking object fixes the issue for me.
In case you have a stable background colour, consider this too.
This is so dumb noone thought about mentioning I guess, eh eh.
I'm using revolution slider and I'm stuck with a problem. As an example I use the original demo from here: https://revolution.themepunch.com/wordpress-photography-slider.
On the tab 'portfolio' you see images that shrink in size with a transition and look a bit darker when you hover over them. This is what I want as well but I can't figure out how.
In revolution slider you can add classes, ID's and CSS to specific images so what I probably need is a CSS code that makes this possible. I've tried several codes I found online but none of them do the trick because they all come with an html part as well.
My guess was: the image is already there, I don't need the html part, only assign classes or id's to the images and then give each image the same kind of CSS code.
Am I on the right track with this? And can anyone help me with the code for it?
Many thanks in advance!
add a class, then do some css
for example:
<img class="slider-img">
.slider-img:hover {
{
let me know if you need help with the css.
EDIT:
try this.
wrap each of your images around 2 divs, slider-img and img-wrap:
<div class="slider-img">
<div class="img-wrap">
<img src="http://science-all.com/images/wallpapers/stock-image/stock-image-15.jpg">
</div>
</div>
then do some css:
.slider-img {
width: 200px;
cursor: pointer;
}
.slider-img img {
width: 100%;
}
.slider-img:hover .img-wrap {
background-color: black;
transform: scale(0.7);
-o-transform: scale(0.7);
-ms-transform: scale(0.7);
-moz-transform: scale(0.7);
-webkit-transform: scale(0.7);
transition: all .5s ease-in-out;
-o-transition: all .5s ease-in-out;
-ms-transition: all .5s ease-in-out;
-moz-transition: all .5s ease-in-out;
-webkit-transition: all .5s ease-in-out;
}
.slider-img:hover .img-wrap img{
opacity: 0.5;
}
basically what the css is doing is that when you hover over the main div (.slider-img), the div containing the image (.img-wrap) gets scaled down by 70% by the css -webkit-transform: scale(0.7);
it also gets a background color of black with an opacity of 80%. this gives the darkened image effect.
-webkit-transition: all .5s ease-in-out; gives a smooth transition effect.
if you are wondering why there are 5 different lines of css for the same thing, thats because each line targets specific browsers. -o- is opera, -moz- is firefox etc.
also, make sure to change the .slider-img width to match your needs.
check out the working example on js fiddle:
here
So, I understand how to perform both CSS3 transitions and animations. What is not clear, and I've googled, is when to use which.
For example, if I want to make a ball bounce, it is clear that animation is the way to go. I could provide keyframes and the browser would do the intermediates frames and I'll have a nice animation going.
However, there are cases when a said effect can be achieved either way. A simple and common example would be implement the facebook style sliding drawer menu:
This effect can be achieved through transitions like so:
.sf-page {
-webkit-transition: -webkit-transform .2s ease-out;
}
.sf-page.out {
-webkit-transform: translateX(240px);
}
http://jsfiddle.net/NwEGz/
Or, through animations like so:
.sf-page {
-webkit-animation-duration: .4s;
-webkit-transition-timing-function: ease-out;
}
.sf-page.in {
-webkit-animation-name: sf-slidein;
-webkit-transform: translate3d(0, 0, 0);
}
.sf-page.out {
-webkit-animation-name: sf-slideout;
-webkit-transform: translateX(240px);
}
#-webkit-keyframes sf-slideout {
from { -webkit-transform: translate3d(0, 0, 0); }
to { -webkit-transform: translate3d(240px, 0, 0); }
}
#-webkit-keyframes sf-slidein {
from { -webkit-transform: translate3d(240px, 0, 0); }
to { -webkit-transform: translate3d(0, 0, 0); }
}
http://jsfiddle.net/4Z5Mr/
With HTML that looks like so:
<div class="sf-container">
<div class="sf-page in" id="content-container">
<button type="button">Click Me</button>
</div>
<div class="sf-drawer">
</div>
</div>
And, this accompanying jQuery script:
$("#content-container").click(function(){
$("#content-container").toggleClass("out");
// below is only required for css animation route
$("#content-container").toggleClass("in");
});
What I'd like to understand is what are the pros and cons of these approaches.
One obvious difference is that animating is taking a whole lot more code.
Animation gives better flexibility. I can have different animation for sliding out and in
Is there something that can be said about performance. Do both take advantage of h/w acceleration?
Which is more modern and the way going forward
Anything else you could add?
It looks like you've got a handle on how to do them, just not when to do them.
A transition is an animation, just one that is performed between two distinct states - i.e. a start state and an end state. Like a drawer menu, the start state could be open and the end state could be closed, or vice versa.
If you want to perform something that does not specifically involve a start state and an end state, or you need more fine-grained control over the keyframes in a transition, then you've got to use an animation.
I'll let the definitions speak for themselves (according to Merriam-Webster):
Transition: A movement, development, or evolution from one form, stage, or style to another
Animation: Endowed with life or the qualities of life; full of movement
The names appropriately fit their purposes in CSS
So, the example you gave should use transitions because it is only a change from one state to another
A shorter answer, straight on point:
Transition:
Needs a triggering element (:hover, :focus etc.)
Only 2 animation states (start and end)
Used for simpler animations (buttons, dropdown menus and so on)
Easier to create but not so many animation/effect possibilities
Animation #keyframes:
It can be used for endless animations
Can set more than 2 states
No boundaries
Both use CPU acceleration for a much smoother effect.
Animation takes a lot more code unless you're using the same transition over and over, in which case an animation would be better.
You can have different effects for sliding in and out without an animation. Just have a different transition on both the original rule and the modified rule:
.two-transitions {
transition: all 50ms linear;
}
.two-transitions:hover {
transition: all 800ms ease-out;
}
Animations are just abstractions of transitions, so if the transition is hardware accelerated, the animation will be. It makes no difference.
Both are very modern.
My rule of thumb is if I use the same transition three times, it should probably be an animation. This is easier to maintain and alter in the future. But if you are only using it once, it is more typing to make the animation and maybe not worth it.
Animations are just that - a smooth behavior of set of properties. In other words it specifies what should happen to a set of element's properties. You define an animation and describe how this set of properties should behave during the animation process.
Transitions on the other side specify how a property (or properties) should perform their change. Each change. Setting a new value for certain property, be it with JavaScript or CSS, is always a transition, but by default it is not smooth. By setting transition in the css style you define different (smooth) way to perform these changes.
It can be said that transitions define a default animation that should be performed every time the specified property has changed.
Is there something that can be said about performance. Do both take
advantage of h/w acceleration?
In modern browsers, h/w acceleration occurs for the properties filter, opacity and transform. This is for both CSS Animations and CSS Transitions.
.yourClass {
transition: all 0.5s;
color: #00f;
margin: 50px;
font-size: 20px;
cursor: pointer;
}
.yourClass:hover {
color: #f00;
}
<p class="yourClass"> Hover me </p>
CSS3 Transitions brought frontend developers a significant ability to modify the appearance and behavior of an element as relative to a change in his state. CSS3 animations extends this ability and allow to modify the appearance and behavior of an element in multiple keyframes, so transitions provides us the ability to change from one state to another, while that animations can set multiple points of transition within different keyframes.
So, let's look at this transition sample where applied a transition with 2 points, start point at left: 0 and an end point at left: 500px
.container {
background: gainsboro;
border-radius: 6px;
height: 300px;
position: relative;
}
.ball {
transition: left 2s linear;
background: green;
border-radius: 50%;
height: 50px;
position: absolute;
width: 50px;
left: 0px;
}
.container:hover .ball{
left: 500px;
}
<div class="container">
<figure class="ball"></figure>
</div>
The above can be also created via animation like so:
#keyframes slide {
0% {
left: 0;
}
100% {
left: 500px;
}
}
.container {
background: gainsboro;
border-radius: 6px;
height: 200px;
position: relative;
}
.ball {
background: green;
border-radius: 50%;
height: 50px;
position: absolute;
width: 50px;
}
.container:hover .ball {
animation: slide 2s linear;
}
<div class="container">
<figure class="ball"></figure>
</div>
And if we would like another in-between point, it would be possible to achieve only via animation, we can add another keyFrame to achieve this and this is the real power of animation over transition:
#keyframes slide {
0% {
left: 0;
}
50% {
left: 250px;
top: 100px;
}
100% {
left: 500px;
}
}
.container {
background: gainsboro;
border-radius: 6px;
height: 200px;
position: relative;
}
.ball {
background: green;
border-radius: 50%;
height: 50px;
position: absolute;
width: 50px;
}
.container:hover .ball {
animation: slide 2s linear;
}
<div class="container">
<figure class="ball"></figure>
</div>
transition can go reverse from middle of the way, but animation replay the keyframes from start to end.
const transContainer = document.querySelector(".trans");
transContainer.onclick = () => {
transContainer.classList.toggle("trans-active");
}
const animContainer = document.querySelector(".anim");
animContainer.onclick = () => {
if(animContainer.classList.contains("anim-open")){
animContainer.classList.remove("anim-open");
animContainer.classList.add("anim-close");
}else{
animContainer.classList.remove("anim-close");
animContainer.classList.add("anim-open");
}
}
*{
font: 16px sans-serif;
}
p{
width: 100%;
background-color: #ff0;
}
.sq{
width: 80px;
height: 80px;
margin: 10px;
background-color: #f00;
display: flex;
justify-content: center;
align-items: center;
}
.trans{
transition: width 3s;
}
.trans-active{
width: 200px;
}
.anim-close{
animation: closingAnimation 3s forwards;
}
.anim-open{
animation: openingAnimation 3s forwards;
}
#keyframes openingAnimation {
from{width: 80px}
to{width: 200px}
}
#keyframes closingAnimation {
from{width: 200px}
to{width: 80px}
}
<p>Try click them before reaching end of movement:</p>
<div class="sq trans">Transition</div>
<div class="sq anim">Animation</div>
in addition, if you want the javascript to listen for end of transition, you'll get one event for each property that you change.
for example transition: width 0.5s, height 0.5s. the transitionend event will trigger two times, one for width and one for height.
Just a summary, thanks to this post, there are 5 main differences between CSS transitions vs CSS animations:
1/ CSS transitions:
Animate an object from one state to another, implicitly by browser
Cannot loop
Need a trigger to run (:hover, :focus)
Simple, less code, limited powerful
Easy to work in JavaScript
2/ CSS animations:
Freely switch between multiple states, with various properties and time frame
Can loop
Don’t need any kind of external trigger
More complex, more code, more flexible
Hard to work in JavaScript due to syntax for manipulating keyframes
I believe CSS3 animation vs CSS3 transition will give you the answer you want.
Basically below are some takeaways :
If performance is a concern, then choose CSS3 transition.
If state is to be maintained after each transition, then choose CSS3 transition.
If the animation needs to be repeated, choose CSS3 animation. Because it supports animation-iteration-count.
If a complicated animation is desired. Then CSS3 animation is preferred.
Don't bother yourself which is better. My give away is that, if you can solve your problem with just one or two lines of code then just do it rather than writing bunch of codes that will result to similar behavior.
Anyway, transition is like a subset of animation. It simply means transition can solve certain problems while animation on the other hand can solve all problems.
Animation enables you to have control of each stage starting from 0% all the way to 100% which is something transition cannot really do.
Animation require you writing bunch of codes while transition uses one or two lines of code to perform the same result depending on what you are working on.
Coming from the point of JavaScript, it is best to use transition. Anything that involve just two phase i.e. start and finish use transition.
Summary, if it is stressful don't use it since both can produce similar result