In this codepen example: http://codepen.io/DrYSG/pen/ovctn I created three flexboxes. The effect I want is that when one hovers over the middle box, it grows in size (color change in the demo is just to help me know about the hover).
In FireFox v19 this almost works correctly. But it is strange what it picks of the start and end widths of the animation.
In Chrome v25, I am getting rapid unstable oscillation of states (flashing). Really not correct.
In IE10 I get the same transition as FireFox, but no smooth transition.
Related
I stumbled upon a weird behaviour in Safari today, and I cannot figure out what causes the problem.
When creating an animation that rotates an SVG element in a certain pattern, with everything working perfectly fine in Chrome, Safari only shows half the SVG on every animation step.
When I remove the background-color: white; from the .container element, everything works fine. How would a background color be causing such a behaviour?
Here's a demo video as well as the corresponding JSFiddle:
JsFiddle: https://jsfiddle.net/04zgmbup/
Chrome (expected):
Safari (unexpected):
Okay, so apparently I got this problem figured out.
Safari seems to be handling the container background as a plane.
This means that when the item rotates, one half will always get rotated behind the container, which has a white background color which covers the element itself.
I still do not know why other browsers do not behave like this.
A possible solution for Safari could be to translateZ(width /2) the element, so that all rotations happen in front of the background plane.
Here's the updated fiddle, working in Safari:
https://jsfiddle.net/04zgmbup/1/
The problem can be visualized nicely by giving the container a semi-transparent background color. In the below recording, one can clearly see that half the circle gets rotated behind the container.
I have a html layout with a navigation bar at the top and a main content area below it, with a left and a right area. The top bar has a background gradient with a hard stop in it. The main content's right area (sidebar) has a background color that should line up with the gradient stop of of the navigation area, at 75%.
See this for a simplified version of my layout. In Firefox and Safari this renders fine, but Chrome puts the gradient stop a little further than it should. I tried to use pixel values instead of percentages, but the behaviour stayed the same.
Any idea why this is happening, and suggested workarounds? Thanks!
Specially with modern browsers that deals with anti-aliasing in so different ways. What i have done was a js fix, (which wouldn't be good for your code :D) also you would have to add a custom padding for each element. But you'll need to hire a freelancer to do it for you, because it would take a while to complete (browser targeting, getting each element, adding padding for each element...)
if u can post the code it would be simple for more possibility.however i am looking for more solutions.
I have a website where I want a linear-gradient to scroll indefinitely to the left. I have it working perfectly right here on codepen: http://codepen.io/spikeyty/pen/oqBFi
It appears that the gradient is there, but it is not moving. I copied the code straight from codepen. Here is the website I'm adjusting: http://tystrong.me
It isn't working in Chrome, Firefox, or Internet Explorer. Any help is appreciated!
Your media query on line 99 (code pen) is wrapping the declaration of the bg-move animation property so it does not exist at the desktop view.
Also - bit of a protip, you don't need to specify from in your animation declaration when it is the default state of the element already.
BTW - sweet little effect!
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!
Check out this fiddle: http://jsfiddle.net/sajYc/
The transition for the :after pseudo element works in firefox, but fails in webkit based browsers. Any idea if this is coming up in a future release? Any non-jquery overkill workarounds for it?
Basically, I'm using it on a page to fade between two states of a background image sprite(instead of two colors like in the fiddle). A smooth transition between an icon's normal and hover state. So I don't want to add a bunch of actual elements to it just to make this animation work.
Unfortunately, this is a known issue in Webkit browsers and IE:
http://css-tricks.com/13555-transitions-and-animations-on-css-generated-content/
However, fading between image sprite states is do-able in jQuery. This tutorial gives a good run down:
http://www.tutorial9.net/tutorials/web-tutorials/creative-button-animations-with-sprites-and-jquery-part-2/