I'm using a basic CSS loading indicator, based on the one from w3schools. It works great except when using IE 10, where it jumps around.
https://www.w3schools.com/howto/tryit.asp?filename=tryhow_css_loader
Does anyone know of a workaround for IE10?
.loader {
...
border-radius: 50%;
animation: spin 2s linear infinite;
...
}
#keyframes spin {
0% { transform: rotate(0deg); }
100% { transform: rotate(360deg); }
}
I made a test with Document mode using developer tools in IE11.
I notice that it shows the result correctly but it also shows a popup to allow block content.
If you allow it then code get break.
with other older versions of IE it not showing any pop up but also not working.
Below is my testing result.
So You can try to make a test without allowing content to check whether it is working with IE10 or not.
Related
I have a WordPress website where I use Visual Composer with fullpage sections. I've added a zooming background using CSS. It's on the following URL: http://white-vision.nl/particulier/
.upb_row_bg {
animation: leaves 20s infinite;
}
#keyframes leaves {
0%, 100% {
transform: scale(1.0);
}
50% {
transform: scale(1.1);
}
}
It looks like it works great, but in Google Chrome when scrolling up (so from 3rd to 2nd section) it gets a white transparent overlay and the videobox is pushed down. When you scroll down (so from 1st section to 2nd section) everything works fine.
This is only a problem in Google Chrome (on Mac and Windows). It works fine in Firefox, Edge and Safari. Does anyone have an idea how to fix this? Thanks in advance!
PS: When deleting the zoom function, there is no problem.
The parent element with classes fp-tableCell vc_row-has-fill is getting a change on its inline styles. One of the properties that are been changed is opacity: 0.107967. This is what makes your background look transparent.
You should try to access this element via javascript and force it to stay at opacity: 1. If you are not able to do that via script, you could force that elements' opacity by adding:
.vc_row-has-fill {
opacity: 1 !important;
}
This will overwrite the changing opacity on the inline styles.
On a Mac, if you hold the Shift key and perform an action that involves animation, it will slow down the animation. For example, hold Shift and minimise a window. This effect is described in various places (e.g. YouTube, Apple - StackExchange, The Unofficial Apple Weblog).
It would be nice to slow down CSS animations/transitions in a similar way. Is there a way to achieve this (apart from simply tweaking the animation-duration value in the CSS)?
You could combine some javascript and CSS to accomplish the effect on a consistent basis, meaning you won't have to go into your code anymore. Heres the code I tried:
function keydown(event){
if(event.which == 16) document.body.className = "slowmotion";
}
function keyup(event){
document.body.className = "";
}
if (window.addEventListener) {
window.addEventListener('keydown', keydown, false);
window.addEventListener('keyup', keyup, false);
} else if (window.attachEvent) {
window.attachEvent('keydown', keydown);
window.attachEvent('keyup', keyup);
}
And heres the CSS:
#keyframes move {
0% {left: 0}
50% {left: 100%}
100% {left: 0}
}
#-webkit-keyframes move {
0% {left: 0}
50% {left: 100%}
100% {left: 0}
}
body > div {
position: absolute;
background: red;
width: 50px;
height: 50px;
background: red;
-webkit-animation: move 4000ms infinite;
animation: move 4000ms infinite;
}
body.slowmotion * {
-webkit-animation-duration: 8000ms !important;
animation-duration: 8000ms !important;
}
And the HTML:
<div>MOVING</div>
What we're doing here is adding a class to the body to indicate we want our duration value overwritten. It will not do it immediately (in Safari it restart the animation) [EDIT: The animation does not get restarted, but gets recalculated (i.e. it reverts to where it would have been in if the other animation had been ongoing)], but it does allow for modification that way. You can even do it for elements with different speeds by doing .slowmotion #myElementID and amending the duration there. Make sure to always include the important, as the class is only triggered when the key is pressed and HAS to overwrite anyway.
Chrome and Firefox developer tools now support slowing down of many kinds of animations.
Chrome:
In the 'Styles' tab of DevTools, look for an 'Animations' icon that opens up the Animations Inspector. More info:
Chrome DevTools Animation Inspector
New animation controls in Chrome Canary
Firefox:
See documentation on working with animations
I am struggling with finding a way to make CSS page transition perform well in google chrome.
In Chrome developer tools on the timeline I noticed some red markers and they all say the same thing: Long frame times are an indication of jank and poor rendering performance. Read more at the Web Fundamentals guide on Rendering Performance.
On the app that I was working on that seemed legit and I tried to investigate, but could not find the source.
I've make a simpler demo and I still get the red marker: http://codepen.io/anything/full/qOOpza/
.page {
position:absolute;
top:0;
left:0;
width:100%;
height:100%;
background:#ccc;
&--1 {
background:green;
}
&--2 {
background: yellow;
}
&.moveToRight {
animation: moveToRight ease .5s;
animation-fill-mode: forwards;
}
&.moveToLeft {
animation: moveToLeft ease .5s;
animation-fill-mode: forwards;
}
}
#keyframes moveToRight {
from { }
to { transform: translateX(100%); }
}
#keyframes moveToLeft {
from { }
to { transform: translateX(0); }
}
I have been playing around with ytour demo, and I found 2 issues:
First, changing from translate to translate3d improves (at least in my system) a little bit the performance. So, writing this
#keyframes moveToRight {
from { transform: translate3d(0%, 0px, 0px); }
to { transform: translate3d(100%, 0px, 0px); }
}
is better. (This has been told several times before, but it is always good to check).
Also, a new property should help somewhat . setting
will-change: transform;
should prepare the browser for a future change in this property. But I haven't been able to see any difference.
Second, there seems to be a problem in the way Chrome gathers statistics.
You have "Screenshots" enabled. And this seems to be the main cause of the delays, the time that Chrome needs to render and store the screenshots.
By definition, the time needed by a performance tool to do its work shouldn't be computed in the analysis. But this doesn't seem to be the case here... I would say this is a bug.
At least in my case, changing both issues makes the red markers almost disappear
And, in the remaining marked frames, there doesn't seem to be any performance issue. Notice in the screenshot that the frame duration is 25.57 ms long, but the CPU time is 1.239 ms .
I'm using SASS so my CSS syntax looks weird, but anyway, the problem is, that my rotate animation starts well on chrome and firefox, but works only partially on Safari. To be specific, rotateY, scale, skew work normally, but rotate and translateX don't. What is more importat, after I go to another tab and then go back in Safari - suddenly it works as expected.
This is the animation in Safari (before switching tabs):
Safari
Instead of that:
Chrome
Basically, all images appear in the center, and only scale and rotateY animation works, but translate and rotate transitions don't.
To keep it simple this is only the part of the code I use for Safari:
#mixin orbit ($name,$time,$modifier,$skewX,$skewY,$perspective,$rotateY,$startScale,$middleScale){
#at-root (without: media) {
#-webkit-keyframes myOrbit_#{$name} {
from { -webkit-transform: rotate($modifier+deg) translateX(150%) rotate($modifier+deg) skewX($skewX+deg) skewY($skewY+deg) perspective($perspective+px) rotateY(0deg) scale($startScale,$startScale); }
50% { -webkit-transform: rotate($modifier+(-180)+deg) translateX(150%) rotate($modifier+180+deg) skewX($skewX+deg) skewY($skewY+deg) perspective($perspective+px) rotateY($rotateY/2+deg) scale($middleScale,$middleScale); }
to { -webkit-transform: rotate($modifier+(-360)+deg) translateX(150%) rotate($modifier+360+deg) skewX($skewX+deg) skewY($skewY+deg) perspective($perspective+px) rotateY($rotateY+deg) scale($startScale,$startScale); }
}
-webkit-animation: myOrbit_#{$name} $time+s linear infinite;
}
I've noticed that when I defined the animation with
-webkit-animation-play-state: paused;
then the "satellites" were positioned properly. So the solution was to start the animation with time offset. In my case this helped:
-webkit-animation-delay: 5ms;
One tricky thing was that I had to put it after other -moz- -o- and "regular" animation properties, otherwise is didn't work, like if it was overwritten.
I have a CSS animation inside of an application we're working on that was working before we started upgrading it to Windows 8.1. It is a relatively simple rotation transform that intended to make an image spin. The below is our CSS which seems valid and runs fine in IE11 with a test page.
.spinner img {
animation-name: rotate;
animation-duration: 2s;
animation-iteration-count: infinite;
animation-timing-function: linear;
}
#keyframes rotate {
from {
transform: rotate(0deg);
}
to {
transform: rotate(360deg);
}
}
It turned out nothing was wrong with the animation declaration itself, as expected. We had just wrapped the keyframes definition inside of a media query. Apparently, even though the media query was valid and was being correctly applied, neither IE11 nor Windows 8.1 would render the animation.
Long story short, moving the keyframes definition outside of the media query resolved the issue.