Leaderboard

There are fundamental logic flaws in the way you're engineering things (if I'm understanding your goal correctly). When you unpause that first tween, it renders at its end state because the parent timeline's playhead is PAST where that tween ends. Since you pause() the timeline, there's no reason for that 2nd tween to render again at that point because it already rendered there and the playhead hasn't moved. I'm curious why you're building it that way. If you think about how those tweens are laid out in the timeline, you'd expect x to jump to 200 and then just stay there (the second tween animates x from 200 to 200, meaning it would look like it's doing nothing). That isn't happening because you're short-circuiting things by pausing the first tween, getting the second one to render and lock in its starting/ending values in a way that's abnormal (ignoring the effects of the first tween), and then circling back and unpausing the first tween after the playhead has already passed its end position. Very very odd in my view. I suspect there's a much cleaner way of accomplishing what you're after that doesn't involve short-circuiting things in odd ways. I mean technically you can force it to render the way you want like this: // OLD pausedFromTweensToggle(false); timeline.pause(); // NEW pausedFromTweensToggle(false); let time = timeline.time(); // record the current time timeline.progress(0).time(time).pause(); // rewind, then jump back to the current time to force everything to render at that state https://codepen.io/GreenSock/pen/yLGoGdY?editors=1010

They seem pretty centred to me, do you have a screenshot of what you find is not centred? Based on your calculation the .first div should move up -12px and it scales should be 0.6786, because each scale step is 0.0357, I've also set to end: "bottom bottom", so now it property ends in the pen. To me this looks like the perfect animation, well build! https://codepen.io/mvaneijgen/pen/zYyEOaR?editors=0010

I remove animation in css codes, and add it after DOM content loaded, i think this is fixed my issue: document.addEventListener('DOMContentLoaded', (e) => { preloader.style.animation="sprite 2s steps(59) forwards"; }); https://codepen.io/MJ-Saei/pen/abPyeoz

Oh thanks . I appreciate you helping me solve my problem, friend. :)))

That makes me a bit nervous, @Aitor. I don't think that's actually a solution. It sure sounds like maybe you accidentally created multiple/conflicting tweens/ScrollTriggers on the same element(s)? Super hard to tell without a minimal demo. Or maybe what you're running into is the refresh() that happens on mobile when the screen resizes due to the address bar showing/hiding. I wonder if ignoring that would help, like: ScrollTrigger.config({ ignoreMobileResize: true }); ?‍♂️

I'm super curious to see what you're talking about ("all kinds of unexpected behavior, added white spaces, etc."). A minimal demo would be super appreciated. Since posting that solution, iOS Safari has changed how it handles things in some cases. For example, on phones it's now impossible (as far as I can tell) to completely prevent that resize, at least without losing other significant functionality. Honestly, Safari has just been terrible. Apple has known about significant bugs for years that they haven't bothered to fix, and they've been unresponsive on the many occasions we've tried to reach out. It's pretty shocking and discouraging. I wouldn't necessarily recommend using that "fix" anymore. I removed it from the helper functions page in the docs now. Have you tried just using ScrollTrigger.normalizeScroll(true)? It can't solve every single problem, but we've invested many hundreds of hours into working around all the various Safari bugs and that's the best we can do at this point. It doesn't need that exact ID, no. The critical thing is that it must be the very ROOT element. Again, "destroyed everything" is super curious to me. Very difficult to speak to this without any demo. I'm really not sure what to tell you, sorry. If you'd like more assistance, please make sure you provide a minimal demo that clearly shows the issue and we'd be happy to take a peek. ?

Hi Policsek, That's a known issue when animating any type of text with anything, not just GSAP. The browser is going to prioritize making the text legible, so it's going to snap to certain values to remain clear. Adding will-change will of course fix that, but that's probably something the dev should make the decision about. MDN put that's warning out there because they don't want people abusing the property, e.g. * { will-change: transform; } Having it on everything can use up too much memory and can decrease performance. The best advice is to just test with and without using will-change. There are no hard rules on how much is too much as it's going to vary by browser and what you're rendering to the screen. I personally have never run into any issues with overusing will-change.

Ahhh! That was it, just started using Bootstrap 5 which has this applied to :root by default. Thanks

Make sure you don't have smooth scroll behavior in your CSS. https://developer.mozilla.org/en-US/docs/Web/CSS/scroll-behavior If you need more help, please provide a minimal demo showing the issue.

v3 version. https://codepen.io/osublake/pen/ExPMgQq

I didn't forget about you. Just kind of busy. Understanding how this animation works is relatively easy. Everything is essentially a ratio, a percent in the range of [0,1]. Even Sine is a ratio, but is in the range of [-1,1]. No matter what number you put into Sine, it will return a number in that range, which is where the up and down motion comes from. The contour of a wave can be created by using a CustomEase, getting a ratio from it, and multiplying it by the height and Sine ratio. Just a little example of what's possible...

EDIT: Notice that a flicker may appear in some of these demos. This a hardware acceleration bug Chrome. You don't need any smoke and mirrors for this. You can create circular motion using Sine.easeInOut, and circular motion is a wave... Look what happens when you plot the x and y values separately. Beautiful waves! Here's how you can do that with SVG. I'm just animating a bunch of SVGPoints on a polyline that are set to slightly different progress values. The amplitude is the height of the wave. The frequency is the distance between waves. And the number of segments is how many points will be added to the polyline. You don't want too many as that can make your animation run slower. Just enough so it looks smooth. You can animate the amplitude and frequency by applying an ease to them. Every ease has a .getRatio() method, which you can use to get the easing value. So if you wanted to animate the amplitude, you could do something like this... point.y = amplitude / 2 * Power1.easeIn.getRatio(norm); To make things interesting, I wanted to test out the CustomEase tool that's going to be coming out soon. I came up with a simple ease that looks like a bell curve, so it starts and ends at 0. Here's how that looks when applied to the amplitude. You can also apply an ease to the frequency/progress value, and even change the shape of the wave. If you reverse your animations, the smooth wave connection gets flipped, creating a pretty interesting sawtooth wave. Related post with other rendering options...