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);
}
Related
I am currently faced with a situation, for which I need to constantly render a flickering animation within a web page. This is currently done by means of CSS, using animation: 0.05s step-end infinite keyframe_name. The keyframe changes the button's background-color at 0% and 50%. As can be expected, using Chrome's Dev tools, this area is constantly being re-painted by the browser, which is leading to an overall poor performance.
I am aware that the use of certain properties, such as the will-change property, or even using the transform: translate3d(0, 0, 0) hack, will enable hardware accelerated rendering. However, opting for either of these options, still hasn't resulted in the desired performance improvement.
The following shows some basic code for what I am trying to achieve (optimizations are not included in code snippet):
#keyframes keyframe_name
{
0% { background-color: red; }
50% { background-color: blue; }
}
button
{
animation: 0.05s step-end infinite keyframe_name;
}
According to a number of online resources, it seems that only the transform and opacity CSS properties make it possible for the browser to optimize compositing. Since neither of these properties can be used to achieve my desired goals, which other approach/es could possibly lead to a performance enhancement, when it comes to the in-browser rendering of such a resource-intensive graphic?
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!
We are running into a weird bug with disappearing elements in the new Firefox (version 34.0.5).
The bug occurs on a page with two (or more) flash objects that are before an other element in the html. Whenever the page is loaded, the element just disappears.
You can see it in this demo:
FF 34 Flash Bug
Just open it in the newest Firefox and you will see the red div disappearing. Every repaint of that page will display it again, e.g switching the browser tab or editing the css via dev tools.
When it does work normally
- One flash file - no matter the position
- Having all flash files after the element in the html
- Having one flash file below and one flash file above the other element (html structure)
What we tried - what it produces
- Repainting the page after flash files are loaded (we are using SWFObject for adding the flash files, but we are not able to attach a load event to the files) - works on the first load of the page (cache clear), doesn't work after refreshes (F5).
- After the page is loaded, scrolling, resizing, changing tabs helps - element is then visible (in some cases)
- Creating an element with width/height with js at the end of the document - helps on first load, after refreshes it doesn't work.
- Animating with css the opacity of the object infinite (we have a wrapper around the flash files and animate this one) - works (not a permanent solution)
- Swf object with a "wmode" other than "transparent" works (not an acceptable solution for us)
What we know
- Bug happens only when MORE THAN ONE FLASH FILE is beneath the element
- Bug happens on flash versions 15 and 16 (these are tested)
- Bug happens in mozilla 34.0.5 (this one is tested)
- Multiple elements after the flash files will also disappear
- When you open the page for the first time, it doesn't show the element. If you then refresh (F5) multiple times, in some cases it will show everything normally, and in some cases it doesn't show the element nor one or both flash files that are overlapping.
Current solution
A constant browser repaint of the disappearing element (or elements!). We do this with a simple CSS3 animation that animates the opacity infinitely between 0.97 and 1 with the duration of 1s.
JavaScript:
if( navigator.userAgent.match(/Firefox\/3[4-9]/i) ){
$('.animation').addClass('firefox34FlashBug');
}
CSS:
.firefox34FlashBug {
animation: 1s linear 0s firefoxFix infinite;
}
#keyframes firefoxFix {
0% {
opacity: 0.97;
}
100% {
opacity: 1;
}
}
That is a very hacky and not a nice solution, but the only "fix" we could find that doesn't change the structure of the html (we need multiple flash files below other elements in our project).
Did anyone else ran into the same problem? We know a couple ways to deal with that behaviour, but we can't explain it yet.
Thank you very much in advance! I hope that we can find a good way of dealing with this problem and that we can find an explanation for the new ninja elements in FF 34 ;-).
Update #1:
Applying border: 1px solid transparent; to a container around every object is fixing it in the demo (also see comments in the answer from akmozo).
This worked for me:
Added to CSS:
.firefox34FlashBug {
animation: 1s linear 0s firefoxFix infinite;
}
#keyframes firefoxFix {
0% {
opacity: 0.97;
}
100% {
opacity: 1;
}
}
Added class="firefox34FlashBug" to my container div outside flash
Note: The demo URL "FF 34 Flash Bug" isn't working, you need to add "index.html" to it. IE http://quickbm.com/ff34flashbug/index.html
Thanks for the fix.
I think that the problem is because your swf objects have absolute positions.
So to avoid this problem, you can put your swf objects into a container and you can use z-index to select it's depth
compared the other elements :
CSS :
.ninja-element {
z-index: 2;
position: absolute;
...
}
.objects {
z-index: 1;
position: absolute;
...
}
HTML :
<div class="objects">
<object>
...
</object>
<object>
...
</object>
...
</div>
<div class="ninja-element">
Watch me disappear in FF 34!
</div>
I had the same problem, but for me it worked to force the browser to repaint just once. After all the SWF Objects are added, I added this line (everything inside of $(document).ready(function() ):
$('#wrapper').css("transform", "scale(1)");
Where #wrapper is a div around the disappearing elements. Scale(1) forces a repaint, but should not change anything about the design (unless you use scale for that element already).
edit:
or maybe better: $('#wrapper').css("-moz-transform", "translatez(0)");, because this will also force a repaint, but only in Firefox.
Just throwing this in there for anyone else.
FF craps the bed when you have a position: fixed element inside a parent element that has been shifted around with left (or something).
To fix this. Shift your parent element around with translate instead.
Spent hours trying to get one of these hacks to work before figuring this out... :(
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