I have animated some of the elements on my page that I am currently working on, and I have assigned an animation-delay for it, so it can show a bit later on. In chrome everything is okay, it gets the assigned value of 1s. But in all other browsers it is being delayed for 2.5 to 3 seconds. How can I fix this?
Here is a reduced case fiddle:
http://jsfiddle.net/sqnkov/E22ZK/
.delayed {
-webkit-animation-delay: 1s;
animation-delay: 1s;
}
P.S>
I have read the MDN post about it being a experimental thingy, but stil - is there a workaround for this issue?
https://developer.mozilla.org/en-US/docs/Web/CSS/animation-delay
The 5seconds comes from .fadeIn which only affects other browsers than Chrome and Safari because you didn't specified a delay for -webkit-
So if what happens on Chrome is what you want, just remove animation-delay: 5s
http://jsfiddle.net/E22ZK/2/
Related
In order to fill the whole height of the page, I use height: 100%; for html and body tags,
and it works fine until a browser would be closed and reopened.
(I don't use 100vh because of issues on mobile devices https://nicolas-hoizey.com/2015/02/viewport-height-is-taller-than-the-visible-part-of-the-document-in-some-mobile-browsers.html )
Steps to reproduce:
Open https://angelika94.github.io/rick/ in Google Chrome on iPhone
(you will see that navigation (Morty and Beer) is placed on the bottom of the page) screenshot of css Rick with navigation
close the browser and remove it from multitasking navigation:
https://support.apple.com/en-us/HT201330
open the browser again (you will see that bottom navigation moved off the "first screen" and now you need to scroll to see it)
screenshot of css Rick without navigation
the page will be fixed by itself in these cases:
update page
rotate the device to landscape
open and close browser's navigation by tabs
close and reopen browser without closing it in multitasking nav
Why does it happen? How can I fix this behavior?
Thank you in advance!
I had a very different issue, but I think the solution I worked out may work for your situation also, because you mentioned updating the page would fix it.
So I had issues with chrome on android where if you scroll very quickly (not uncommon on mobile), some elements would fail to get re/painted. Searched everywhere for a solution but couldn't find anything that would work.
Finally, I figured out a working fix:
.pagewrap {
transform: translateZ(0);
animation-name: 'repaint';
animation-duration: 3s;
animation-iteration-count: infinite;
animation-play-state: running;
animation-timing-function: linear;
}
#keyframes repaint {from { zoom: 99.99999%; } to { zoom: 99.99998%; }}
So what this does is forces the page to continually repaint on a 3 second cycle.
Maybe I should tweak it to only shift for a fraction of a second every 2 seconds, instead of continually:
.pagewrap {
transform: translateZ(0);
animation-name: 'repaint';
animation-duration: 2s;
animation-iteration-count: infinite;
animation-play-state: running;
animation-timing-function: linear;
}
#keyframes repaint {
0% {
zoom: 99.99999%;
}
99% {
zoom: 99.99999%;
}
100% {
zoom: 99.99998%;
}
}
I tried zoom: 99.99999; to 1 but certain elements that transitioned scale above 1 on some hover effects would show the zoom breathing. So 99.99999 to 99.99998 was what worked for me to make the effect invisible.
Slightly hacky solution that could present performance issues for very long pages, but maybe not, because the browser should only be rendering what's onscreen. The pages I used this on are graphically heavy with a lot of complex multi-layer effects, and this doesn't seem to have a noticeable performance impact.
Seems like many mobile browsers have excessively optimized rendering, which leads to quirky failures with few well documented fixes. Forcing repaints was the only working fix I found.
I tried other, slightly less aggressive, documented methods of forcing repaints. Like adding some text to the page (invisibly) after scrolling stops for 200ms, and such. Nothing worked though, thus my animate-the-entire-page-forever hack.
In your case, some of those other hacks may work better. This article outline all the various things that cause repaints/reflows so you could try doing some of these things via script.
Light way to fix an issue:
Firstly, a tiny js-code*:
function defineVisibleHeight (){
const h = window.innerHeight * 0.01;
document. documentElement.style.setProperty('--vh', `${h}px`);
}
defineVisibleHeight();
window. onresize = defineVisibleHeight; // not mandatory;
*code sample has extra whitespaces to prevent plain copy/paste
With a previous code we found out a true visible area of a screen and stored it as variable for stylesheet;
Finally, css:
.wrapper{
height: calc(var(--vh, 1vh) * 100);
}
i'm trying to apply a css animation to the root element of a page and it's behaving strangely. you can see it here: http://dinakelberman.com/bucket/circle-test.html
html {
display:block;
transition-duration:1.5s;
background:#E3DCB1;
background-image:url(http://vignette.wikia.nocookie.net/leapfrog/images/b/be/Yellow_Circle.png/revision/latest?cb=20180115233859);
background-size:100%;
animation:rotate 0.5s linear infinite;
}
#keyframes rotate {
0% {transform:rotateY(0deg) rotateX(0deg);}
100% {transform:rotateY(360deg) rotateX(360deg);}
}
in chrome & opera the animation progresses only when the mouse moves
in safari it animates on its own as expected
in firefox it doesn't animate at all
i don't need a solution as to how to make this animation visible by using other elements, i know this is a weird and wrong way to do things.
i'm doing some experimental work where i'm trying to deal exclusively with the root element. i don't really dislike the behaviors but ideally i'd like the results to be the same across browsers so i'm curious about how they're handling this differently.
I created a path in illustrator and then used some CSS in order to animate it. The svg animation works just fine in Chrome and Firefox, However, for a strange reason in safari it's animated backwards! The site is http://www.rw.limdez.eu and is located on the very top banner of the website. You can see it as soon as you click the link! You can only see this on desktop since for mobile it redirects you to the mobile version of the page! This is the CSS I used:
.smallline
{
stroke-dasharray:692;
stroke-dashoffset:-692;
animation-delay: 1s!important;
animation: draw-smallline 8s 1 forwards;
}
#-webkit-keyframes draw-smallline
{
0%{
stroke-dashoffset: -692;
}
100%
{
stroke-dashoffset:0;
}
}
Note1: I also tried it without #-webkit- but i have the exact same results!
Note2: I have seen other very similar questions to mine in stack-overflow but none of them were answered. Not in a way that solves my problem at least! Thank you.
Negative works fine in Safari.
Instead of:
stroke-dasharray:692;
You should use:
stroke-dasharray:692 692;
This was fixed by changing the 0% dashoffset from -692 to 692! If i am not mistaken this occurred because safari does not deal efficiently with negative values!
I am trying to loop the divs A, B, C, D continuously and in order using the z-index but I am unable to get the timing right.
I have a codepen here
Any help would be greatly appreciated.
Thanks
I wasn't able to get the timing right for the alternate animation, but here's a working loop that works perfectly, but without alternating:
http://codepen.io/anon/pen/wtqLA
Changes:
animation: move 4s linear infinite; -> animation: move 16s linear infinite;
.block-b {animation-delay: 4s;} -> `.block-b {animation-delay: 8s;}
.block-c {animation-delay: 8s;} -> `.block-b {animation-delay: 12s;}
.block-d {animation-delay: 12s;} -> `.block-b {animation-delay: 16s;}
Also I've added an extra keyframe so that the animation only starts changing z-index at the end of the animation, for better timing:
#keyframes move {
0% { z-index: 0; }
50% { z-index: 0; }
100% { z-index: 10; }
}
I hope this is good enough for you. I couldn't get it to work properly with alternating directions
CSS3 animations are not yet out of the "experimental" phase in some browsers. As you can see here, WebKit browsers (including Opera) still need a prefix to work properly. I am assuming you're testing it in one of the browsers that require the -webkit- prefix. It works perfectly when I open that page in Firefox.
I've added the prefixes that make the animation work in all browsers here.
I realise this is not an answer to your question, but it is a very serious problem if you would want to publish it anywhere.
I am trying some CSS3 keyframe animations in a web app I'm developing. I have tried both my own custom animations and some provided by animate.css. The result is the same: the animation works fine, but after a while, even if I leave the browser alone, the CPU usage goes up to around 100% and stays there. Killing that process kills the web app, removing the CSS animations gets rid of the problem, so there is no doubt what's causing it. I am mainly using Chrome, and that's where I have seen the problem so far.
Target platforms for the web app includes iOS and Android via Phonegap, Windows and OSX via node-webkit. The problems I describe do not seem to occur in mobile Safari, but what about other platforms? Is this a general problem with keyframe animations? Are there any tricks to avoid this?
EDIT: Added demo link, but unable to replicate the problem. In the full app I am using a number of libraries and frameworks, like AngularJS, Angular-UI, Angular-UI-router, Fastclick, Animate.css, etc. I guess they might interfere somehow? Hard to say, but removing my animations from the app also removed the delayed 100% CPU usage.
HTML:
<button id="start">Start</button> <button id="reset">Reset</button>
<br/>
<div id="ball" class="ball"></div>
Javascript:
document.getElementById('start').addEventListener('click', function(e) {
document.getElementById('ball').classList.add('remove');
});
document.getElementById('reset').addEventListener('click', function(e) {
document.getElementById('ball').classList.remove('remove');
});
CSS:
.ball {
width:100px;
height:100px;
border-radius:100px;
background-color:darkred;
position:absolute;
top:100px;
left:200px;
}
#-webkit-keyframes slide {
from { top:100px; left:200px; }
to { top:100px; left:-100px; }
}
.remove {
animation: slide 1s linear;
-webkit-animation: slide 1s linear;
-webkit-animation-iteration-count: 1;
-webkit-animation-fill-mode: forwards;
}
The cause of the 100% CPU usage is due to the -webkit-animation-fill-mode: forwards declaration, if my suspicion that you're doing your primary testing on Chrome is correct.
It looks like it's a current bug with Chrome (tested on version 30.0.1599.101), according to an article by Wercker and my own research:
For this animation we use animation keyframes and the
-webkit-animation-fill-mode: forwards; so that the sidebar retains its position from the last frame of the animation. An animation normally
would snap back to its original setting after it is finished playing.
This is great for us, but not for Chrome. The CSS animations using
-webkit-animation-fill-mode: forwards; are causing the 100% CPU load bug. It actually only occurs when the CSS animation ends and the tab
is inactive.
This seems to be corroborated by this issue on the Chromium project page.
As Lindsey Bateman says in the article, the bug is fixed in Chrome Beta and Chrome Canary (33.0.1706.0 canary), so we shouldn't be waiting for very long to get this into current Chrome.
If you're using 3d (eg even if not, some recommend tricking CSS into 3d to let the GPU help render), try this trick via mddw
translateZ(0) /* only needed if no CSS-3d commands are used to toggle GPU rendering */
-webkit-backface-visibility: hidden;
-webkit-perspective: 1000;
backface-visibility: hidden;
perspective: 1000;
I got rid of the problem by disabling all extensions. It remains to be investigated which one was responsible. These are the suspects:
AngularJS Batarang 0.4.3
avast! Online Security 8.0.1500
ColorZilla 0.5.4
HootSuite Hootlet 4.0.10
iGetter 2.9.2
Intel® XDK 2.6.1
Ripple Emulator (Beta) 0.9.15
Xmarks Bookmark Sync