I am creating a website for a project and got stuck with an issue.
I was trying to implement the hover feature, where when I hover over the image it gets zoomed in. That part works nicely, however, I was having an issue when I hover over the last book in the first row. When I hover over that, the entire screen becomes glitchy. This feature is not working as I hoped, i.e. smooth and good to work with. I have attached the image and the code I have.
Thanks for any help!
.books img{
width:200px;
height:300px;
}
.books img:hover {
position: relative;
left: 45px;
width: 300px;
height: 400px;
display: block;
}
I found some code online using -mox-transform and -webkit-transform, however, I have never worked with that before. This seemed complex for me. Any suggestions if I should learn how that works instead of perfecting the above code?
By increasing the width and height on hover the surrounding layout must adapt to that size change. The browser must move the surrounding elements to provide the space for the larger element, that is why it is glitchy.
If you want to do it properly, you will probably have to use transform, as you mentioned.
For your use case it should not be hard. Try this:
.books img {
width: 200px;
height: 300px;
transition: transform 200ms; /* optional transition with 200ms duration */
}
.books img:hover {
transform: scale(1.1); /* scale to 110% */
}
All you need to use is scale property to scale the image. Change your code to this
.books img:hover {
transform: scale(1.5);
}
This should do what you are looking for.
Use transform CSS Property with scale() which is used to increase or decrease the size of an element
.books img:hover {
transform: scale(1.2);
}
Related
CSS transform scale() function appears to have a bug on Safari when it's used on elements with a border.
I'm trying to zoom an image on mouse over using transform: scale() function but if the image has a border then it gets pixelated when scaled.
Here is a sample of the same element with the same CSS rules applied (except the border):
Code example: https://jsfiddle.net/m6g4kw30/
div {
text-align: center;
}
img {
height: 100px;
-webkit-transition: all .3s ease;
-moz-transition: all .3s ease;
-o-transition: all .3s ease;
-ms-transition: all .3s ease;
transition: all .3s ease;
border: 1px solid #000;
margin: 20px;
}
img.noborder {
border: none;
}
img:hover {
-webkit-backface-visibility: hidden;
backface-visibility: hidden;
-webkit-transform: translateZ(0) scale(5);
-moz-transform: scale(5);
-ms-transform: scale(5);
-o-transform: translateZ(0) scale(5);
transform: translateZ(0) scale(5);
}
<div>
<img src="https://via.placeholder.com/1000.png" alt="">
<img src="https://via.placeholder.com/1000.png" class="noborder" alt="">
</div>
CSS transform scale() function appears to have a bug on Safari when it's used on elements with a border.
You can say that again! Unfortunately, the reported bug(s) for this (and similar) issues go back many years, with the following bug referenced in most:
https://bugs.webkit.org/show_bug.cgi?id=27684 (Opened in 07/2009)
If you didn't catch the date, it's a 10 year old bug that's still causing developers issues today! YIKES.
Basically, the issue comes down to Safari rasterizing the layer. On transform/scale, it resizes the layer, however it does not re-render the rasterized layer. In your use-case, the rasterized image is scaled up, but the text/image is blurry.
As for a workaround/fix? There are a couple ways you can "address" this:
1) Force a re-render
A quick/easy fix is to force Safari to re-render your layer when you transform. One way this can be achieved is by applying a CSS property which you then change after transforming (some people have success changing a background-color, for example). For your specific use case, I had luck with the following combination:
img {
outline: 1px solid #000;
border: none;
}
img:hover {
outline: none;
border: 1px solid #000;
}
By toggling those specific values, I was able to force Safari to re-render the rasterized layer, thus rendering a sharp image (similar to the non-border example). Here's a JSFiddle with the full code example: https://jsfiddle.net/gc56brfh/
2) Scale down, then up
Another workaround, documented here, is to set the element's initial size to the "scaled up" dimensions, and then scale down the element until you're ready to scale it up. That way, the element is rasterized to the correct dimensions.
CSS wise, that may look like:
img {
-webkit-transform: translateZ(0) scale(0.2);
height: 250px;
}
img:hover {
-webkit-transform: translateZ(0) scale(1);
}
In the above, we've set the initial size of the img to 250px (this is based on your original css, with images being 50px and then scaled up 5). We then scale down the image by 0.2, resulting in 50px. On hover, we then scale back up to 250px by setting scale(1).
Here's an updated JSFiddle: https://jsfiddle.net/df2zqgnx/
One thing to note is that other CSS properties might need to be updated with this workaround. For example, you'll notice in the fiddle I also needed to update the border from 1px to 5px to compensate for the scaling down.
Anyway, hope this was helpful and one of the solutions works for you!
This is a bit of a long-winded question, but I hope someone can break this down for me. I have 2 questions:
Why a CSS property doesn't do what it should.
Why this particular CSS property works on an unsuspecting element, and why it doesn't work on the CSS :hover selector.
Created a flipcard animation. Got some graphics/trailing lines issues with transitions (in Chrome).
Doing some Googling, I found out that apparently, using -webkit-transform: translate3d(0,0,0); is supposed to fix the issue by using hardware acceleration.
However, I couldn't figure out where to place this CSS property. I tried placing it on the .flipcard-container, .flipcard, on the actual transition (.flipcard-container: hover .flipcard).
None of these removed the trailing lines caused by the animation.
Question 1: Where can I use the -webkit-transform: translate3d(0,0,0); properly in order to take advantage of the hardware acceleration, and why does/doesn't it work there?
But, after doing even more Googling and copying someone else's code, I found adding perspective: 600pxto the .flipcard-container somehow fixed the issue. And on top of that, it even makes my animation look really nice.
It shouldn't bother me so much, but it does that I cannot figure out why this worked.
According to the MDN docs:
The perspective CSS property determines the distance between the z=0
plane and the user in order to give a 3D-positioned element some
perspective.
Question 2: Why does this work in my transition so well? Shouldn't I have to place perspective in .flipcard-container: hover .flipcard instead of the .flip-container?
Of course, when placing it in the css :hover selector, the entire transition stops working. Does the perspective property also use hardware acceleration?
Here is the code, and thank you in advance.
.flipcard-container {
height: 400px;
width: 300px;
/* uncommenting the below property will fix the issue */
/* -webkit-perspective: 600; */
}
.flipcard-container:hover .flipcard {
transform: rotateY(180deg) scale(1.5);
}
.flipcard, .front, .back {
width: 100%;
height: 100%;
}
.flipcard {
transform-style: preserve-3d;
transition: all .8s ease-in-out;
}
.front {
background: #6093e5;
position: relative;
backface-visibility: hidden;
}
.back {
background: #e56060;
position: absolute;
backface-visibility: hidden;
top: 0;
transform: rotateY(180deg);
}
<div class="flipcard-container">
<div class="flipcard">
<div class="front"></div>
<div class="back"></div>
</div>
</div>
Question 1
You are overriding the transform: tags with the hardware acceleration. This causes that the animation doesn't work if you put it in.
You can use this, to archive better (more stable fps)
.flipcard-container:hover .flipcard {
transform: rotateY(180deg) scale(1.5);
will-change: -webkit-transition;
will-change: transition;
}
it uses the new will-change property.
More details
The will-change CSS property provides a way for authors to hint
browsers about the kind of changes to be expected on an element, so
that the browser can setup appropriate optimizations ahead of time
before the element is actually changed. These kind of optimizations
can increase the responsiveness of a page by doing potentially
expensive work ahead of time before they are actually required.
Question 2
If you look at e.g. this:
https://codepen.io/jfcorugedo/pen/bBPWaO?q=3d+turn&limit=all&type=type-pens
you see that it also uses the perspective tag. It is used that you can see the rotation of the box (like in your case).
If you remove it, it looks like your code. It works only on the container because the object you want to flip is wrapped in it.
If you have more questions just ask :)
I am trying to do a simple image fade on rollover - works fine and smooth in Chrome, but Firefox is a bit jumpy. I've tried doing the backface-visibility trick on the container, but still no luck.
Anyone have any ideas?
JSFiddle
HTML
<div class="link-box large">
<div class="image">
<img src="https://encrypted-tbn0.gstatic.com/images?q=tbn:ANd9GcRStwH3maKRqLU8lLOo1XbO6uZIKHRyf2PGv66H6ol5mB0kS_0r" alt="">
</div>
</div>
CSS
.link-box .image img { transition: all .2s ease-out; width:200px; }
.link-box.large { position: relative;}
.link-box.large:hover .image img { opacity: .65; }
My best guess is that setting the width of the image to 200px and leaving the height unspecified is causing the browser to calculate the height of the image. If the height calculates to a nice whole number it isn't an issue. If the height calculates to a decimal it may be the cause of the problem.
In this case the natural dimensions of the image are 275px by 183px.
By changing the width of the image to 200px you are shrinking the image to 72.727272...% of its natural size.
275/200 = 0.727272... Or if you prefer fractions: 275(8/11) = 200
Now running the same equation on the height yields:
183(8/11) = 133.090909...
It looks like, under the normal run of things, the partial pixels are cropped, but during the transition the partial pixels aren't being cropped, and the image is warped slightly to show the partial pixels within the same height.
Cropped down to 133px:
Not cropped and slightly warped:
Now that we have a good hypothesis on what's causing the problem, on to the solutions:
You can hard code the height of the image:
Working Example
.link-box .image img {
transition: all .2s ease-out;
width:200px;
height: 133px; /* manually set the height */
}
Or if you would rather not hard code the height, you can also fix the issue with an anti-alias hack, just add a box-shadow.
Working Example
.link-box.large:hover .image img {
opacity: .65;
box-shadow: 0 0 0 #000; /* add a non-visible box-shadow */
}
Or if you're concerned about the cross-browser compatibility of using a box-shadow, you can also use a transparent border:
Working Example
.link-box .image img {
transition: all .2s ease-out;
width:200px;
border: 1px solid transparent; /* add transparent border */
}
Works good on my Firefox.
Anyway you can try to add some special attributes that will prepare the browser for the transition and actually render the element with possible transformation in mind.
Such an attribute is transform: translate3d(0,0,0);
Like this :
.link-box .image img {
transition: all .2s ease-out;
width:200px;
transform: translate3d(0,0,0);
}
.link-box.large { position: relative;}
.link-box.large:hover .image img { opacity: .65; }
My issue is that during CSS transition border-radius temporarily stops clipping elements inside if transition of overlapping element involves transform. In my case I have two divs absolutely positioned one above the other where the first one has transition triggered by action on clicking a navigation element inside the second one, like:
<div id="below"></div>
<div id="above"><div id="nav"></div></div>
The above div has border-radius: 50% and clips the nav div. In CSS it goes like (minimal example, original onclick action illustrated as :hover):
#below {
position: absolute; width: 250px; height: 250px;
-webkit-transition: all 1s linear;
transition: all 1s linear;
}
#below:hover {
-webkit-transform: rotate(45deg);
transform: rotate(45deg);
}
#above {
position: absolute;
width: 200px; height: 200px;
border-radius: 50%;
overflow: hidden;
}
#nav {
width: 40px;
height: 200px;
background-color: rgba(0,0,0,0.3);
}
Of course it is better visible in http://jsfiddle.net/UhAVG/ with some additional styling for better illustration.
This works as expected in IE10+ and FF25, also in Chrome 31 and 32 with hardware acceleration disabled. In result only accelerated Chrome shows this unwanted behaviour. So I'm wondering if it's possible to workaround it somehow using current CSS3 techniques.
After some more experiments I've finally found the solution. Sometimes simple ones are the hardest to find. In this case #above {z-index: 1;} (like in http://jsfiddle.net/UhAVG/1/) solves the issue. Wild guess is that z-index prevents some optimization that combines operations from single layer and doing so mistakenly optimizes out applying border-radius on element. With layers separated this is no longer the case.
I am applying 2 CSS3 transitions to a image. Everything works fine. Only issue. The image wobbles while upscaling. Is there any way to smoothen this out?
DEMO
CSS
div{
width:199px;
height:253;
margin-left:50px;
margin-top:50px;
}
div:hover
{ -webkit-transform: scale(1.2);
-webkit-filter: hue-rotate(180deg);
-webkit-transition:all 2s linear;
}
EDIT: Somehow I notice that the issue is not with the upscale property. If you remove the hue-roate property the images upscales without any jitter. However I need both the effects in my animation.
I placed the transition on the img and transitioned the width instead of scale and it seemed to fix the wobble
FIDDLE
div{
margin-left:50px;
margin-top:50px;
}
img
{
width:199px;
}
img:hover
{ width: 238px;
-webkit-filter: hue-rotate(180deg);
-webkit-transition:all 2s linear;
}
The problem is that the image is being scaled up along different axes at different times because it is not a square image and the floating-point dimensions are being truncated to integers.
The only fix that exists is to artificially make the image element square so that the two dimensions of the image are scaled up in sync, which will eliminate the perceived jitter.
Though, if I could get away with it, I probably just reduce the transition time so that the jitter is not as noticeable.