CSS Opacity Transitions on :active elements affect other elements [duplicate] - html

I have an issue where my css3 transformations are effecting other elements on the page and even causing them to sort of flicker. I saw another post about this but they didn't have a resolution with the issue.
http://scosha.mybigcommerce.com/w107b/ when you scroll over the navigation you see an animated css3 transformation. It works fine in firefox without flickering but with chrome and safari the effect is very obvious, you see it in the drop down menu items as well as the footer text.

Working solution for flickering elements during transition in Chrome is to set up CSS for parent node:
-webkit-backface-visibility: hidden;

The solution for me was to apply the bellow css to the parent of all affected elements.
-webkit-transform-style: preserve-3d;
-webkit-transform:translate3d(0,0,0);

This is a known issue with Macintosh text rendering on Chrome 22 (and apparently Safari). GPU acceleration causes MacOS to switch from subpixel to greyscale antialiasing which makes the font weight appear to decrease noticeably.
Update:
As the OP notes below, the fix is to apply -webkit-font-smoothing: antialiased - which applies grayscale anti-aliasing at all times. If you do this, you'll probably want to increase your font-weights all around since greyscale anti-aliased text looks notably thinner than sub-pixel
You can get the same effect by applying properties that cause the content to always be GPU accelerated (such as back-face-visibility: hidden) but because these are not guaranteed to cause GPU acceleration in future browser versions - it is more future proofed to simply specify greyscale.

I was having the same issue in Chrome but not Firefox.
The temporary fix is to add a web-kit fix and remove the transition:
-webkit-transition: none;

Related

Background image of element flickering during CSS transition in webkit

I'm having an issue where I have a CSS transition on my page (the header shrinks when you scroll down) and while the transition is occurring the background image of another element is flickering/shaking in webkit (Firefox is perfect). I've seen that people have had similar issues and I've tried the many different solutions offered out there such as adding:
-webkit-backface-visibility: hidden;
-webkit-transform:translate3d(0,0,0);
But have had no luck.
You can see an example of it here: http://jsfiddle.net/ojdavey/9sesxy0y.
Any help would be much appreciated.

Firefox CSS and/or D3 difference

So I've got a page on a site that displays exactly like it should in both IE and Chrome, but not Firefox. The link is http://www.jakerevans.com/?page_id=61. In both IE and Chrome, the spinning animation (written with D3.js) displays fully through the padding-left and padding-top, but not in Firefox. Anyone have any idea how I can make this padding in Firefox transparent? Any other possible solutions? I'd really like to resolve this through CSS if possible, and not go back to the drawing board with the D3 code. Obviously I will if I have to though.
Thanks a lot for the help!!!
You need to explicitly set overflow: visible on your <svg> element.
The SVG specifications state that all SVG elements that create viewports should have overflow: hidden in the browser's default stylesheet. However, browsers disagree over whether this should include the padding area or not: if you follow the description in the SVG specs, as Firefox does, padding would not be included. However, general CSS/HTML layout does not consider content in the padding to be overflow, so Webkit/Blink/IE browsers do not clip it with overflow:hidden.
it doesn't seem to be the issue of the padding, it's like to be the firefox transform origin thing, see this Setting transform-origin on SVG group not working in FireFox

Clipping Issue during 3d transform in Safari only

I am having an interesting problem with clipping while performing a 3d rotation. I am rotating an element using :
-webkit-transform: rotate3d(0, 1, 1, 180deg);
During the animation it looks fine in Chrome, Firefox, and any other browser except for Safari.
The window is clipping through the elements behind it.This shouldn't be a z-index issue as I have assigned proper z-index to these elements.
Anyone know what could be causing this to happen just in Safari?
This is what is looks like in Safari during animation:
And properly animated in Chrome
Thanks!
Try setting the container of the rotated modal transform-style: flat and a new perspective. You need to change 3D rendering context.
This is related answer https://stackoverflow.com/a/18167565/1663572 -- but you probably don't want to change the position on Z axis as it changes the appearence dramatically. I couldn't use it also.
It's been a while, but I had the same issue, and actimel linked to an elegant workaround. (Though as they stated, it'll only work the background elements aren't already transformed 3D.)
Add these two lines to the background elements (or a container with those elements inside, or a class that all of those elements are part of):
-webkit-transform: translateZ(-1000px);
-webkit-perspective-origin: 100% 100% none;
Good luck future readers! :)
It could be that in the version of safari you are using, z-index is not well supported Check can I use.com

Very difficult to solve and strange CSS3 opacity transition issue (...must be a bug?)

I am absolutely tearing all of my hair out with this highly frustrating and strange CSS problem I am having.
I am using the Bones boilerplate to make a website, and it has been great, until now...
It uses fluid grid system and I have recently tried to create a simple gallery which I have made into a grid (4 images, each one wrapped in a quarter column, with first/last classes added to the first/last images).
If you hover over the images (especially noticeable on the first three for some reason), you will notice that they change width by a pixel or two for some crazy reason. The images are set to max-width:100%, and I have a feeling this is somehow the culprit, because if you give the images a "fixed" width (example .gallery-icon img {max-width:165px;}, it fixes the issue, but being a fluid grid system, I can't go down that route, as the images stay 165px if resizing the browser, and even if I set 4 different widths depending on media, in between media sizes, the images wouldn't align properly.
If it wasn't for the transition effect problem (if i turn the transition off, the images lower opacity fine, but no animation), it would work as I want it to work :(
Please help guys!
Here is a empty demo site that has the bones boilerplate running and nothing more than the gallery on the page. Let me know if you see the shaking issue.
(I couldn't recreate it on jsfiddle, so I installed it on an old domain I had lying around hehe)
EDIT: I have just noticed that the problem seems to happen to images that are bigger than the div in both width and height. Images 1 + 3 are this and they have the bug, whereas images 2,4 seem to be okay? and images 2+4 have a smaller height than the div..... But even if I set the images a max-height, the problem continues..
EDIT2: Added a quick video to show the problem (latest Firefox and Chrome) http://www.youtube.com/watch?v=uL81hLfMvvw
Thanks to vals for pointing out the GPU aspect... This reminded me of this CSS-Snippet which tends to solve Chrome rendering issues:
-webkit-transform: translateZ(0);
I've applied this to the container (div.post) containing the problematic item (i.icon-) which has a fraction width, problem solved!
Credit: I've got this solution from this answer to fix incorrectly rendered (fixed) elements after navigating to an page anchor.
I would say that it is really a bug in Chrome (I am using 24.0.1312.57 m).
The issue is not really on images 1 + 3, I have seen it on image number 2.
I think that the issue arises when you have the width of the image being a fraction (say 146.71 px). In stationary display, this gets rounded to 146 px. In the transition this gets rounded upwards (more correctly !) to 147 px.
use the following css hint to promote the affected element to a new composite layer (It solved the same exact issue to me):
.<your-css-selector> {
will-change: <css style about to change. example: opacity>;}
This indicate the compositor to isolate the paint process of the element into a new composite layer. When inspecting layers in chrome dev tools you can make sure the element has been promoted, and thence the issue solved. The element will appear in a new layer with the following 'Compositing reasons: has an active accelerated animation or transition. Has a will-change compositing hint.'
Looks like after promoting the element to a new layer this way, the browser is able to render the final state of the transition correctly.
Ivan.
On thins link you can find solution for Mozilla bug.
You need to add 1 CSS rule:
-moz-backface-visibility: hidden;
I suggest using jQuery to handle your opacity rather than using the CSS3 attributes because you are correct in that your max-width is messing, unhappily, with your transitions.
$(".gallery-icon img").hover(function(){
$(this).fadeTo(fast, 0.7);
}, function(){
$(this).fadeTo(fast, 1.0);
});
Using jQuery will fix a lot of these little glitches with transitions and make sure your opacity change is done cross-browser-compatibly (yes, I know that there are lots of tags for transitions for browsers, but there aren't attributes for all browsers.) :) Hope that helps!

-webkit-transform rotate - Pixelated images in Chrome

Using -webkit-transform: rotate(-5deg); on a container div, Chrome renders the grid of images with really jagged edges. Whereas in FF (-moz-transform:) and IE (-ms-filter:) everything looks OK - see the difference below.
Is there any thing I can do about this?
You could check out the answer to the question css transform, jagged edges in chrome
Helped me out
From the accepted answer:
In case anyone's searching for this later on, a nice trick to get rid
of those jagged edges on CSS transformations in Chrome is to add the
CSS property -webkit-backface-visibility with a value of hidden.
In my own tests, this has completely smoothed them out. Hope that
helps.
It appears to be an Antialiasing bug in the webkit engine. A report has been filed but is as yet unsolved.
You can try adding a border the same color as your background to try to minimise the effect.
-webkit-transform: rotate(-5deg) translate3d( 0, 0, 0);
Does the trick for chrome.
Have you tried the CSS rule -webkit-transform-style: preserve-3d;?
You could also try rotating the specific axis with -webkit-transform: rotateZ(-5deg);.
I encountered this issue on Chrome 33 (Windows 7). I tried all the suggested fixes on this page. Misery ensued. My rotation was pretty simple:
transform: rotate(40deg);
-moz-transform: rotate(40deg);
-webkit-transform: rotate(40deg);
I found this answer and after some quick experimentation I found that the following combination works perfectly in Chrome:
-webkit-backface-visibility: hidden;
outline: 1px solid transparent;
I haven't tested cross browser yet. I have no idea which further bugs this introduces. You have been warned. Hope this points someone in the right direction.
Side note: During my experiments I found that -webkit-backface-visibility: hidden; (on its own) removed the antialiasing from untransformed images.
This is a WebKit bug that has been already fixed and the fix shall appear in Chrome 15.
The workaround until everyone updates to 15+ is to apply -webkit-backface-visibility: hidden; to the element being rotated. Worked for me. That triggers antialiasing on the element.
You can add box-shadow to your images with the same color as your background, that reduce the effect.
example:
http://antialiasing-webkit.qip.li/edit/
This won't be appropriate for all uses, but where you have control over the markup and don't mind adding an extra <div>, you can make use of generated content to dramatically clean up the edges of rotated images in Chrome. This works because Chrome will apply anti-aliasing to the generated content placed over the image.
You can see an example here: http://jsfiddle.net/cherryflavourpez/2SKQW/2/
The first image has nothing done to it, the second has a border applied to match the background colour - not any difference that I can see.
The third image div has some generated content with a border placed around the edge. You lose a pixel around the edge, but it looks much better. The CSS is pretty self-explanatory. This has the advantage of not requiring you to create the border in your image, which seems like too big a price to me.
For me it was the perspective CSS property that did the trick:
-webkit-perspective: 1000;
Completely illogical in my case as I use no 3d transitions, but works nonetheless.