I'm using filter:grayscale(1) on images. The container of the image also have pseudo :after applied with a background color set to mix-blend-mode:screen. Everything seems to work, except on Safari iOS.
Here's the CSS for the images isolated:
.grid-item img {
filter:grayscale(1);
transition:filter 0.25s ease;
}
.grid-item:after {
content:"";
position:absolute;
top:0;
left:0;
right:0;
bottom:0;
display:block;
z-index:1;
mix-blend-mode: screen;
transition:opacity 0.25s ease;
pointer-events:none;
}
.grid-item.is-active:hover img {
filter:grayscale(0);
}
You can see the whole site here: http://www.tobiasgerhardsson.com/work/linazedig
And here's a video showing it live: https://streamable.com/a6lxe
The bug is hard to explain, but it seems like it's moving images in between the others, so that some images gets duplicated and replaced with the same image, or fragments of other images are shown in eachother. It disappears on scroll, but sometimes the bug appears again randomly.
I've tried to remove the mix-blend-mode as I thought that was causing the bug, but the bug only disappears when I remove the filter:grayscale(1) from the images. I'm also using a JS plugin for doing a flexbox masonry grid layout on desktop. But I've also removed the script temporarily, and the bug remains.
So all in all, this seems to be a problem with the filter:grayscale, but I'm not sure if it's caused by a combination of other CSS properties or not. Has anyone experienced this before and know what could be causing it? Or is it just a bug not possible to solve?
Reading this thread, I found that applying the following properties to the element with the filter makes the glitch go away:
-webkit-transform: translateZ(0);
-webkit-perspective: 1000;
-webkit-backface-visibility: hidden;
Working on a website today I found myself in the position (haha...) that a logo that I wanted to fix to the viewport didn't stick anymore. In my research to resolve this problem I learned that position: fixed won't fix to viewport if the ancestor element has a transform on it (see positions-fixed-doesnt-work-when-using-webkit-transform).
I made sure not to have any transforms on my element (or it's ancestors), I even tried to remove all child elements (which happen to have transforms and animations on them) – but I still didn't manage to get things going.
I am sort of clueless right now, so I made a jsfiddle for others to look at. The element that needs fixing is the bright red .titles element: http://jsfiddle.net/ZWcD9/90/
remove transfrom from body
body {
width: 100%;
/* -webkit-transform: translateZ(0); */
/* transform: translateZ(0); */
}
I've messed about with z-index until I'm blue in the face on this one now.
It's no doubt going to be simple though.
Please view this website and hover over 'Why Us' in the navigation menu. The dropdown menu appears behind the slider. I'm sure it must only be a z-index / position issue but I've not managed to see where the problem is.
(Not posted jsFiddle or code because imagine it will be quicker for you to identify issue directly in browser/on website).
You can solve it with z-index alone (plus fixing the overflow, too, so not really alone, I guess).
header.container {
overflow: visible;
z-index: 2;
}
#page.container {
overflow: visible;
z-index: 1;
}
There are two issues. This does the trick:
nav.container {
overflow: visible;
z-index: 1000;
}
The z-index doesn't solve it alone, as the sub menu is cutted by the hidden overflow of the <nav>-element.
dont forget to add
header.container {
overflow: visible;
z-index: 2;
position: relative // without this sometime z-index doesnt work
}
There seems to be an issue with my page here:
http://www.lonewulf.eu
When hovering over the thumbnails the image moves a bit on the right, and it only happens on Chrome.
My css:
.img{
-ms-filter: "progid:DXImageTransform.Microsoft.Alpha(Opacity=50)";
filter:alpha(opacity=50);
-moz-opacity: 0.5;
opacity: 0.5;
-khtml-opacity: 0.5;
display:block;
border:1px solid #121212;
}
.img:hover{
-ms-filter: "progid:DXImageTransform.Microsoft.Alpha(Opacity=100)";
filter:alpha(opacity=100);
-moz-opacity: 1;
opacity: 1;
-khtml-opacity: 1;
display:block;
}
Another solution would be to use
-webkit-backface-visibility: hidden;
on the hover element that has the opacity.
Backface-visibility relates to transform, so #Beskow's has got something to do with it. Since it is a webkit specific problem you only need to specify the backface-visibility for webkit. There are other vendor prefixes.
See http://css-tricks.com/almanac/properties/b/backface-visibility/ for more info.
For some reason Chrome interprets the position of elements without an opacity of 1 in a different way. If you apply the CSS attribute position:relative to your a.img elements there will be no more left/right movement as their opacity varies.
I had the same problem, I fixed it with css transform rotate.
Like this:
-webkit-transform: rotate(0);
-moz-transform: rotate(0);
transform: rotate(0);
It works fine in major browsers.
Another solution that fixed this issue for me was to add the rule:
will-change: opacity;
In my particular case this avoided a similar pixel-jumping issue that translateZ(0) introduced in Internet Explorer, despite fixing things in Chrome.
Most of the other solutions suggested here that involve transforms (eg. translateZ(0), rotate(0), translate3d(0px,0px,0px), etc) work by handing painting of the element over to the GPU, allowing more efficient rendering. will-change provides a hint to the browser that has presumably a similar effect (allowing the browser to render the transition more efficiently), but feels less hacky (since it's explicitly addressing the problem rather than just nudging the browser to use the GPU).
Having said that, it's worth bearing in mind that browser support is not as good for will-change (though if the issue is with Chrome only then this might be a good thing!), and in some situations it can introduce problems of its own, but still, it's another possible solution to this issue.
I was need apply both backface-visibility and transform rules to prevent this glitch.
Like this:
a {-webkit-transform: rotate(0);}
a img {-webkit-backface-visibility: hidden;}
I had a similar issue with (non-opacity) filters on hover. Fixed by adding a rule to the base class with:
filter: brightness(1.01);
backface-visibility (or -webkit-backface-visibility) only fixed the issue in Chrome for me. To fix in both Firefox and Chrome I used the following combination of above answers.
//fixes image jiggle issue, please do not remove
img {
-webkit-backface-visibility: hidden; //Webkit fix
transform: translate3d(0px,0px,0px); //Firefox fix
}
I encountered a similar issue in Safari 8.0.2, where images would jitter as their opacity transitioned. None of the fixes posted here worked, however the following did:
-webkit-transform: translateZ(0);
All credit to this answer via this subsequent answer
I ran into this issue with images in a grid each image was nested in an that had display: inline-block declared. The solution that Jamland posted above worked to correct the issue when the display: inline-block; was declare on the parent element.
I had another grid where the images were in an unordered list and I was able to just declared display: block; and a width on the parent list item and declared backface-visibility: hidden; on the image element and there doesn't seem to be any position shift on hover.
li { width: 33.33333333%; display: block; }
li img { backface-visibility: hidden; }
The solution alpipego was served me in this problem.
Use -webkit-backface-visibility: hidden;
With this the image no move in hover opacity transition
/* fix error hover image opacity*/
-webkit-backface-visibility: hidden;
-moz-backface-visibility: hidden;
-ms-backface-visibility: hidden;
backface-visibility: hidden;
I had trouble with all the other solutions here, as they require changes to the CSS that may break other things -- position:relative requires me to completely rethink how I'm positioning my elements, transform:rotate(0) can interfere with existing transforms and gives wonky little transition effects when I have a transition-duration set, and backface-visibility won't work if I ever actually need a backface (and requires a whole lot of prefixing.)
The laziest solution I found is to just set an opacity on my element which is very close to, but not quite, 1. This is only a problem if opacity's 1, so it's not going to break or interfere with any of my other styles:
opacity:0.99999999;
Having marked Rick Giner's answer as correct I then found out it did not fix the issue.
In my case I have responsive width images contained within a max-width div. Once the site width crosses that max width the images move on hover (using css transform).
The fix in my case was to simply amend the max width to a multiple of three, three columns in this case, and it fixed it perfectly.
I noticed you had opacity included in your CSS. I had the same exact issue with Chrome (the image moving on hover) .. all I did was disable the opacity and it was solved, no more images moving.
.yourclass:hover {
/* opacity: 0.6; */
}
Had the same issue, My fix was putting the class before the src in the img tab.
I'm trying to implement a div slider into a standard iScroll HTML page, please see the below links:
With iScroll (slide not working properly):
http://utvecklingspunkten.se/iscroll.html
Without iScroll (slide working):
http://utvecklingspunkten.se/iscroll2.html
For some reason, iScroll hides the content (not the div containing it!) in the second div slide. The div containing the content is there allright and it's corretly possitioned (have a look in the console), but the content is simply hidden by iScroll. When removing all references to iScroll, as in iscroll2.html, everything works as it should.
Wrapper containing both slides:
#wrapper {
position:absolute; z-index:1;
top:45px; bottom:2px; left:0;
background:#aaa;
-webkit-transition-property: left;
-webkit-transition-duration: 400ms;
display:block !important;
}
Each sliding element:
.additional-block {
position: absolute;
display:block !important;
}
Does anyone know how I can make iScroll and the slider to work together, and not interfere? Hopefully, there's only a line of code or two in iscroll.js that need to be changed. Likewise, an iScroll div (like the artificial scrollbar) overlaping my second slide div is another possible reason. Pointing this out for me would be greatly appreciated. Thanks!
Try using jQuery Slider, you can style it inside out. Plus you have there already mouse dragging and scrolling ( which actually works ).