We've moved an SVG/JS animation created with the Adobe After Effects Bodymovin plugin from one Wordpress site to another. On the old site (which I unfortunately can't show you), the animation works flawlessly. On the new site, depending on the size of the browser window, the animation contains glitches that appear to be caused by some sort of rounding error in the animation mask.
On one or more edges of the globe, you can occasionally (depending on viewport width) see a one pixel-wide bit of the scrolling background graphic appear. See image.
I've isolated the animation in CodePen. It works fine here, no matter what size the viewport is set to.
However, when I introduce this tiny bit of CSS such as this...
margin: 0 auto;
width: 70%;
... into the style of the parent DIV, the glitch starts happening. See here.
On the original animation, the mask extends a lot further than the edges of the globe, so I suspect the fact that the mask now just reaches to the edges of the globe is some sort of Bodymovin optimization.
Given that this doesn't happen on the old site, I suspect there is some sort of CSS, or perhaps a setting in Bodymovin, that stops this from happening.
The Wordpress site is built with Divi, and the animation sits in a DIV nested inside many other DIVs (ie a module sitting in a column sitting in a row sitting in a section), and most of these DIVs have the width set to various percentages. So I don't think the solution will lie in simplifying the CSS.
Has anyone experienced a problem like this before? Or have suggestions that might help eliminate it?
I have also created an Issue in the Bodymovin GitHub page, but the response times there seem to vary greatly.
I have made some testning on the codepen and was able to make it work when i removed
transform: translate3d(0px, 0px, 0px);
so removing this line of the script should fix the problem
this.svgElement.style.transform="translate3d(0,0,0)")
Why are you trying to transform the svg, when its already transforming automaticly.
This is a possible fix if you still want to retain the settings with margin and width %.
You can avoid this issue by giving a width in pixels to #container the responsiveness of percentages sometimes causes pixels to be just slightly off. Use media-queries if you need to have different sizes for other screen dimensions.
#container {
margin: 0 auto;
width: 400px;
}
Related
I am a paid user of the Ninja Slider responsive image slider script (CSS/Javascript) and it always has worked pretty well. Unfortunately, though, Google now is warning that it is causing an unacceptably large CLS (Cumulative Layout Shift) placed in a responsive layout. I am optimistic that someone on Stackoverflow has tweaked this code — or similar code — and can help.
This slider loads quickly enough on my connection that it is difficult for me to even see this shift, but I agree that any shift could be troublesome and I would like to fix it accordingly. Essentially, I would like to modify the code so it quickly outlines a dynamic box the size of the image that will be loaded before loading the image so the following text doesn’t shift down should the user scroll past and start reading before the first image in the slider loads.
In Google’s default Optimize Cumulative Layout Shift advice, the company recommends adding the width and height of an image — like in the pre-responsive days — and adding height: auto to the img code in CSS like so:
img {
width: 100%; /* or max-width: 100%; */
height: auto;
}
This works for images displayed directly in the dynamic layout, but not for images within the slider code because the images are not presented as an img tag, but instead presented as links (a href tags) within list items in an unordered list.
I nevertheless tried dutifully adding height: auto in the applicable CSS file where I thought it could be relevant, within the #ninja_slider div and slider-inner classes. This didn’t break anything, but it didn’t solve the issue, either. Default CSS code is here.
As requested, I believe this this the relevant code, but I could be wrong, and viewing the full code might be useful:
#ninja-slider {
width:100%;
background:#191919;
padding: 30px 0;
margin:0 auto;
overflow:hidden;
box-sizing:border-box;
}
#ninja-slider .slider-inner {
max-width:600px;
margin:0 auto;/*center-aligned */
font-size:0px;
position:relative;
box-sizing:border-box;
}
This post on StackOverflow is the only relevant one I was able to dig up, and the answer suggests that adding display: none on “blocks” using CSS classes would resolve the issue.
Based on my understanding of how display:none works, I assumed this would just prevent the slider from appearing, but I nevertheless tried adding it to the ninja_slider div as well as the slider_inner classes and ul and li elements. It did not work. My code is similar to the default, but if a live implementation is helpful, it is here.
What am I overlooking? How can I alter the slider code to quickly display a box that will soon hold the image so that subsequently placed text will remain in place and not be pushed down when the image loads? Thank you.
Your CLS score is essentially telling you that the layout is shifting as its loading. The best advice one can give in a situation like this is
Hit F12 on the page in question to open Developer Tools
Navigate to the network Tab
Set the Network Speed Select value to 3G
Refresh the page with Developer Tools still open to see a slow motion load of the page which allows you to identify Which elements are "shifting" the layout and changing size as page loads.
You want to be able to define all your element sizing early on in the head of the page using a style tag in the of that page or within the stylesheet (if you must,I believe putting too much inside the stylesheet and depending on things like grid sizes to load defeat this purpose due to sheer size of the css files eventually negates any positive or it wont be seen quick enough as the User is still waiting for the CSS File to load).
Using the above method you can then try to apply CSS that will prevent the Size Shifts , and example of this is with image attribute heights.
This is a tricky topic because you have to also understand CSS casscading (the understanding of style application heirachy essentially) to prevent causing new responsive image issues because the width and height attribute will most like override the current image styling on your page.
What I would honestly suggest is a click function that initates or accesses the slider on click only because the waiting of the entire slider to load and then it shifting the container to a different size is what is causing the actual problem.
I'm working on an enjin site for a friend and cannot for the life of me understand how to make the page here stretch to fill the whole screen vertically if the content does not have enough in it to do it on it's own. I've tried scripts and CSS of a dozen or more solutions and cannot understand how to make it do this because it's not my code, its Enjin's, and I have to work around it.
There are 2 pages in question, one is a standard format page so anything done to it can be done to all pages except the custom one and there will be no problems, and the other is a custom coded page using their HTML module. The key is the same solution is necessary for both but they have different code.
Custom Page: X |
Standard Page: X
Simply put I'm asking for a solution here. I tried the flex solution, height 100% with block display, javascript to find the distance between the bottom of the bottom div and the bottom of the monitor and adjust height accordingly, and more. Nothing seems to work. Any help is very gratefully appreciated.
I can provide any more details necessary, just ask.
What you are trying to accomplish is 2 things. First you want to make the div #memberContainer always be at least as tall as the users screen minus the height of your footer.
This can be acomplished with css using the "vh" unit. The vh unit is defined like this:
Relative to 1% of the height of the viewport*
And the calc function, as you will need to subtract 100vh (the screen height) from the height of your footer (180px).
So you need to add this code to your #memberContainer.
#memberContainer{min-height: calc(100vh - 180px)}
The second thing you need to do is make sure the background image of #memberBlock always covers the entire visible portion of the screen.
The image itself is 1920*1080, which is a standard 16:9 resolution. Assuming you only wanted to target 16:9 screens this would work fine. However to cover mobile phones and all other screens I would recommend you use:
#memberBlock{background-size:cover}
This makes sure the image will always cover the screen.
You can't have no gap and no content to fill it. There will have to be a gap somewhere.. Your gap is appearing in the middle because the footer is absolutely positioned. If you stop positioning your footer absolutely, the footer will cling to the body-wrap, however, you will still have a gap at the bottom, it just won't look as bad.
.myfooter {
display: none;
width: 100%;
position: relative;
background-color: RGB(20, 20, 20);
height: 180px;
bottom: 0;
}
If you really wanted to make it fit the screen, you could give a min-height with a calc of 100vh-FooterHeight
position: absolute;
height: 100%;
There may be other issues with this as i have no idea how mobile or responsive stuff would work for your site specifically but this is one way. You are coupling the BG div to the content div - that is why you are seeing that behavior - you need to make the BG a sibling div of content instead of a parent child relationship then you can have more flexibility on how it works - but for now my option seems to work
I'm building a parallax scrolling website (aren't we all) that amongst other things, reveals an image as the user scrolls.
I've done the 'reveal' by putting the image in the background, and placing a solid filled div on top. I then animate this div from 100% height to 0% height based on the scroll position, thus revealing the background image.
I'm doing this kind of thing multiple times and unfortunately I'm getting slow down.
Using Chrome's built in Timeline feature, I can see that most of this slow down is from Image Decodes. For the above reveal, it's re-Decoding the image every frame, which takes 22ms per image per frame.
Does anyone know when the browser needs to do Image Decode and when it doesn't? It seems obviously to me that it would need to if I resized the image, but not that it would need to when I just half cover the image?
Thanks for your help.
I've battled with this problem a lot also. As yet I have not found anything concrete and my proposed solution does not seem to work in ALL cases and I have not been able to ascertain why.
Anyway...
It appears that when you animate a solid element over the top of an image, chrome forces a recode of the image.
There are two things I have tried and for the most part they have been successful.
If you add -webkit-transform : translate3d(0,0,0) to the covering element, you should find most, if not all of the image decodes disappear.
If adding the above CSS to the covering element itself does not help, try adding it to the image instead, or indeed try adding it to both elements.
My understanding is that using the 3d css property pushing the image into its own composite layer which is cached and handled by the GPU rather than the browsers software renderer.
90% of the time I have found one of the above combinations successful. I hope it helps.
How do you animate the property? I think you may have plenty of alternatives to just animating the height (which is some sort of resize of the container).
Maybe it's less intensive to just 'clip' the background image with another element. I found a thread about it on StackOverflow with some suggestions. If you animate with javascript, unfortunately pseudo elements are no option...
Clip/Crop background-image with CSS
I am working on a website and added an animation of clouds flowing using adobe edge animation.
http://avuedesigns.com/iaq/
I have created a thread over at the adobe community (http://forums.adobe.com/thread/1128782) and it seems that my code to make it responsive, and the overflow are correctly setup.
So basically I have no idea why WordPress is either breaking it. Or why my little bit of code thinks the website is wider than it really is. Maybe fresh eyes can see something I am not.
correct your container has an overflow attribute most likely set to scroll within your css file.
set this to;
overflow: hidden;
Well, wordpress is just a cms engine that spits out html - it is hardly to blame. I do see that the width keeps changing and the horiz scroll bar appears and disappears which is definitely not optimal.
I think the starting place is with the main container div....do you have overflow:hidden set? This should allow your clouds to appear outside of the visible pane without forcing the div to change width.
I'm animating elements using -webkit-transform: translate3d(x,y,z) and the cubic beizer timing function combined with touch-events for the iPhone to make a custom scrollmethod type thing.
Trouble is, the animations stutter (element stops for half a second) if the elements (in this case page div's) are above a certain size. If I have width 320px and height of 1000px, this all works just fine, but if I make the height 2000px I get a nasty stutter. Note that it only stutters once in the beginning, almost like it's loading and then it's fine.
Are there any known work-arounds?
Two possible workarounds.
First turn off other CSS properties, namely position (top, left, right, bottom), and opacity. Mixing them, especially if they are animating, can cause performance issues.
You could try experimenting with turning off as much as possible, and seeing if the issue is then fixed. If so, then turn them back on one by one, until the problem property is found.
Second, wrap your content within an iframe. Even if the iframe is set to fill the view, it can give a significant performance improvement, when it contains very large images.