GreenSock

Are you saying you only want to apply ScrollSmoother to a nested <div> that scrolls horizontally? If so, no, ScrollSmoother is made for vertically scrolling the entire page. Sorry. There are a whole bunch of complexities and magic is has to apply to do that properly. It can't be done in the same way for a nested <div>. Technically you could probably sense wheel/touch events (maybe with Observer plugin or just vanilla), prevent the default behavior in the event (event.preventDefault()) and tween the scrollLeft value. Not exactly simple, but probably feasible with some elbow grease

I'm not personally familiar with Netlify, but this post may help: https://blog.privjs.com/article/how-to-install-club-greensock-packages-on-netlify And this one: Or: Thanks for being a Club GreenSock member! 💚

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. 👍

I don't see any jumping at all, but you're running into that issue with Apple browsers related to graphics rendering (a browser issue, not GSAP) that we already discussed in your other thread. Try adding this at the top of your code: gsap.config({force3D: false}) Does that help at all? The reality is that you're asking a LOT of the browser graphics-wise when you scale something up that huge. The browser has to calculate all those pixels, even the ones off-screen. The more pixels you ask the browser to render, the harder it is on the CPU/GPU.

Hi @L Waterfield. I'm curious why you thought that was a solution. You can't animate to a className like that. Also, whenever you find yourself making tons of "if/else" statements like that or lots of the same code for every section, it's a clue that you could probably simplify it a lot with some loops or functions. Here's how I'd do it: https://codepen.io/GreenSock/pen/mdawXMb Notice you could add as many sections/dots as you want, and you don't need to touch any of the code. It automatically adjusts. Does that help?

Yep, each tween can only have one ease. That's a performance optimization. If you need a different ease, then you're doing it exactly the right way. 👍

By default, ScrollTriggered animations get immediately rendered so that they are ready to go super-fast when the scrolling gets to that spot. So since you've got several tweens animating the SAME element(s), they're all using the same initial state as the "start". Solution: just set immediateRender: false on the subsequent tweens of the same element(s) so they user the ending state of the previous one when they first render. https://codepen.io/GreenSock/pen/ExGmBva?editors=0010 - OR - You could use .fromTo() tweens that define the starting and ending states (so they're not dependent at all on other tweens). - OR - You could put them all into a timeline. Lots of options Happy tweening!

Yes, just to reiterate, it had nothing to do with a problem with ScrollTrigger or a bug in 3.12.2. It was simply that you made a mistake in what you were defining as your containerAnimation (you had the wrong type of object). Since version 3.5.1 never even recognized that property at all because it didn't exist back then in that version, it was simply ignored. But in 3.12.2, it was trying to work with that containerAnimation you passed in...but that wasn't a valid container animation, thus it threw that error. Does that clear things up?

Sorry to hear about the trouble, @josephjcox. It's super difficult for us to troubleshoot by just looking at screenshots and an excerpt of the code - can you provide a minimal demo that clearly illustrates the issue? Like a CodePen or Stackblitz? Based on the error message, it kinda seems like whatever you're feeding in as "flagfix" might not be a valid GSAP animation (tween or timeline). Once we see it in context, I'm sure we'll be able to figure out more of what's going on. You might want to console.log(flagfix) and see what it is. Thanks for being a Club GreenSock member! 💚🥳

It looks like you're using React and you didn't do proper cleanup which is critical in React. As of React 18, it double-invokes your useEffect()/useLayoutEffect() which is super annoying because it causes people to inadvertently create DUPLICATE (conflicting) animations/ScrollTriggers. That's why we created gsap.context() - it makes cleanup super easy. That was explained in the article @Rodrigo asked you to read. https://stackblitz.com/edit/react-a881rw?file=src%2FApp.js Does that help?

Welcome to the forums, @ethanp You've come to the right place. First of all, ScrollMagic is not a GreenSock product and it's very very old and has no ongoing support. I'd strongly recommend switching to our ScrollTrigger library which is far more capable and it integrates perfectly with GSAP. Secondly, it looks like you're trying to control the path drawing manually by animating the strokeDashoffset which you can do but there are various "gotchas", like the one you ran into there where the browser leaves a little bit behind when the length isn't calculated exactly right. In your case, you've got a stroke width of 5, thus even when the offset should be sitting at exactly the start, you'll have 2.5px of stroke still showing. So you probably need to offset the length value by 2.5 or 3. If you use DrawSVGPlugin, it solves issues like that for you automatically (and several other cross-browser inconsistencies/bugs). It's a members-only plugin, though. https://greensock.com/club Look how much simpler it is with ScrollTrigger and DrawSVGPlugin: https://codepen.io/GreenSock/pen/yLGbXjm?editors=1010 I'm not sure exactly when you want things to trigger or if you need things staggered or whatever, but that should give you a good starting point. Enjoy the tools!

Can you explain what you mean by "...makes a horrible click"? I'm struggling to understand what you think the problem is. I'm probably missing something obvious, but it seems to be working exactly as it should. I wonder if you just have the "start" value set to a higher value than you need(?) If you still need help, please provide a minimal demo, like in CodePen or Stackblitz that only shows the essential code to illustrate the problem (don't include your whole project). Some colored <div> elements is adequate. We just can't effectively troubleshoot a live site where it's impossible to quickly tweak the code and poke around.

One other thing to keep in mind: only the animations/Draggables/ScrollTriggers that are created when your gsap.context() function is invoked will get added to the context (and get reverted when ctx.revert() is subsequently called). It looks like you're creating additional ones AFTER that function is invoked, like inside an onPress or onDrag or onDragEnd. Those won't get reverted the way you've got it set up now. To make sure those get added to the context properly, make sure you do ctx.add(() => {...your code here...}) as explained in the docs.

@AvaterClasher you already asked this previously and we offered feedback. It's entirely possible, but not at all simple. You'd have to figure out the coordinates of the control points and use a mousemove/pointermove listener to affect them based on proximity and then update the "d" attribute of the <path> accordingly, probably in an onUpdate of a tween. If you need further assistance with that, you'll probably need to hire someone to work it all out. Feel free to contact us about paid support services or post in the Jobs & Freelance forum. Good luck!

Thanks for pointing that out, @Thibka! ✅

You definitely shouldn't be calling contentHeight() on every resize because that's creating a duplicate tween and ScrollTrigger every time, so they're fighting with each other. And you're baking the initial height into the "end" value, so it's not getting updated on refresh. So just change this: gsap.to(container, { y: () => -(height - document.documentElement.clientHeight), ease: "none", scrollTrigger: { trigger: document.body, start: "top top", end: () => `${height}px bottom`, // <-- changed to a function! scrub: 1.5, invalidateOnRefresh: true } }); Since invalidateOnRefresh is true and it uses function-based values, those will get re-invoked on refresh. If you still need help, please make sure you provide a minimal demo that clearly illustrates the issue, like in CodePen or Stackblitz.

That's a rendering thing in Safari. When it applies GPU acceleration, think of it like it takes a screenshot of the element at its "native" size and then just stretches those pixels when you scale. You can try adding this to the top of your code: gsap.set("#wrapContainer", { force3D: false }) Which disables the GPU acceleration (transforms don't get a 3D one applied if it's not necessary) Or you can change the way you set things up so that your "native" element size at the biggest value you need, and then scale up from a much smaller value. In other words, instead of scaling 1 -> 10 you can build it as if it's naturally at the 10x size (natively) and scale from 0.1 -> 1. That way, the "screen capture" is much more detailed and high-resolution.

If you'd like some help, please make sure you provide a minimal demo that clearly illustrates the issue and we'd be happy to take a peek. It sounds like maybe the Observer plugin could be useful. https://greensock.com/docs/v3/Plugins/Observer Good luck!

I'm not sure exactly what you're looking for there, but maybe this?: https://codepen.io/GreenSock/pen/GRPWMJo?editors=0110

Do you mind me asking why? That seems incredibly wasteful. "resize" events fire VERY frequently, so doing all those calculations constantly while the user is resizing seems like it'd be terrible for performance and deliver very little benefit visually.

I don't have time right now to do it for you, but there are several ways... Just temporarily set the tween's totalTime(), read the value, then set it back. For example, if you know your click tween has a duration of 1 second, then set the other tween's totalTime() forward by 1, like otherTween.totalTime(otherTween.totalTime() + 1), read the value(s), then set it back so the user will never actually see a jump. Do the math. Your rotation is going at 1 full rotation over the course of 30 seconds, so that's 360 / 30 degrees per second. Calculate what it'd be 1 second in the future that way and plug the values in. I hope that helps!

Welcome to the forums, @theKVD. Here's one approach: https://codepen.io/GreenSock/pen/PoXWypj?editors=0010 You just needed a way to keep track of that timeline instance so you could revert() it. Right?

It looks to me like you're using the wrong end values. You're animating to where the rotating box is NOW (when creating the tween) rather than where it will be by the time the tween's duration completes. So you'd just have to figure out where it will be after that amount of time and animate there.

It looks to me like this line is the problem: $("#nav").css({"top":$("#intro").height()}); You're forcing the initial CSS to be a very specific height there which gets locked into the tween as the "revert" value. Since you're doing a .fromTo() tween anyway, this line of code is completely unnecessary. https://codepen.io/GreenSock/pen/bGOgagp?editors=0010 There's no need for jQuery either, FYI. Nor do you have to create a whole separate tween and ScrollTrigger. Is that what you're looking for?

First of all, nice job on the site. It looks sharp. 👏 It's super difficult to troubleshoot by just looking at a screenshot, and we can't diagnose issues on a live website, but if you'd like more help please make sure you provide a minimal demo. No need to use CodePen - you can use this Next Starter Template Please share the StackBlitz link directly to the file in question (where you've put the GSAP code) so we don't need to hunt through all the files. Once we see an isolated demo, we'll do our best to jump in and help with your GSAP-specific questions.