css animation applied to root element behaving strangely - html

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.

Related

CSS transitions queue up instead of playing simultaneously - only in Safari and Chrome

I have a site on which I'm transitioning everything between light and dark mode on the flip of a switch.
I'm doing this by giving the body tag a color and background-color which change, and everything on the page is styled using * { transition: color 1s, background 1s; }.
In Firefox, this does exactly what I want. In Chrome and Safari, it has the horrible effect of seemingly queueing up the transitions by... tag name?
Eg. First the container fades, then text, then italic text, then headers, then code blocks, etc. etc.
I haven't the foggiest why this would cause a render engine quirk. Is Firefox right? Is there a spec for this at all? I'm hoping to have the whole page fade at once.
To be clear, the left is Firefox - that's the desired outcome. The right is Safari being very strange, though Chrome is exactly the same.
Here's a link to the site if you'd like to try it out in your browser.
Remove below code:
* {
transition: color 1s, background 1s
}
and add transition property to the body selector
html, body {
transition: all 1s;
}

iOS Chrome calculates the wrong height of the document

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);
}

SVG animation animates backwards in safari

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!

Animate Z-index in a continuous loop with css3

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.

Optimize a CSS3 animation that uses CSS masks

I'm working on a CSS3-based animation, where I have a div that has a linear-gradient as the background, and then I use a PNG as the mask using the -webkit-mask-image property.
To make it animated, I want to move the mask on top of the gradient. It's working fine and looks gorgeous, but my issue is it kinda kills the CPU.
Here's the animation:
#keyframes moveMask {
0% { -webkit-mask-position: 0px 0px;}
100% { -webkit-mask-position: 2000px 0px; }
}
And I'm calling it using this:
animation: moveMask 200s linear infinite alternate;
I've tried to add the following trick, but it didn't change anything:
transform: translate3d(0,0,0);
-webkit-transform: translate3d(0,0,0);
Any idea on how I can optimize it?
As Rich Bradshaw pointed out, I think you will find that it's just not very well optimized. To achieve a similar sort of effect though, you could create an animated GIF, double the canvas size, and then place a static version of the GIF on every frame of the other half of the canvas. That way, the animation would always be playing invisibly in the background and you'd just switch to it by changing the position of the image whenever you wanted to show the animated version.
A problem with this technique is that the animation won't necessarily start at the beginning when you trigger it. That may or may not be important for your particular animation.