GreenSock

From your screen capture, it kinda looks to me like a thread synchronization issue caused by the fact that modern browsers perform scrolling on a totally different thread that's not synced with the main JS thread. Have you tried either using ScrollTrigger.normalizeScroll(true) -OR- ScrollSmoother to ensure that the scroll-related updates are done on the main thread?

This might also be helpful: There's a special ease you can apply that'll help keep the path sorta centered as you scroll. https://codepen.io/GreenSock/pen/bGOvaJR?editors=0010 Thanks for sharing!

This is definitely beyond the scope of help we can typically provide in these free forums because there's a lot of custom logic necessary, but here's a rough idea of a different approach that hopefully helps get you going in a better direction: https://codepen.io/GreenSock/pen/mdaxepQ?editors=0010 If you need more assistance, you're welcome to contact us about paid consulting services or post in the "Jobs & Freelance" forum. Good luck! 👍

@Sublimio yes, it'd be much better to start a new thread for a new question like that. The problem is that you're animating the element (or parent of the element which of course also animates the element itself) that's used as the trigger. That's almost always a bad idea because it'll throw off all the start/end calculations. What you're asking to do can’t happen automatically. In this particular case you could attempt the calculations manually, like this: https://codepen.io/GreenSock/pen/poqLJGX?editors=1010 I hope that helps. If you still need assistance, please start a new thread.

That's just a logic thing related to the fact that your very first color-changing section is below the trigger area So you can either add an invisible section that fills that top area as a trigger to go back to the transparent state, or you can add some conditional logic that'll animate back to the initial state in the onLeaveBack() of the very FIRST section: https://codepen.io/GreenSock/pen/oNJEWXx?editors=0010 Is that what you want?

If you'd like some help, @aln, please provide a minimal demo (like a CodePen) showing what you're trying to do. The overall concept illustrated by the BlurPlugin above should apply to whatever property you want - you just have to adjust the code in the plugin to target that property.

Just set markers: false (instead of true).

Oh, that's lovely to hear, thanks @grizhlie. And nice job on the site. 👏

Great question. I've thought a LOT about this and on the surface it seems like a great idea, but consider the following: The more modular, the less cacheable and "packagable". Currently, the "gsap" core object is super capable and robust. It has things like gsap.to(), gsap.timeline(), gsap.utils.*, gsap.ticker, gsap.globalTimeline, eases, etc., etc. Everything is very reliable, consistent, and ever-present. Load one file, and BOOM, you've got a ton of power at your fingertips. GSAP has been standardized on almost every ad network on the planet so that its file size doesn't count against ad budgets. Just one CDN had over 13 BILLION requests for GSAP in a single month. If we busted everything apart into little modular pieces, that might be nice for build tools but it'd be terrible for CDNs and browser caching. Please read this article: There are lots of inter-dependencies in the core. For example, tweens get put onto a global timeline, so you can't effectively separate Tweens and Timelines. Various internal functionalities rely on some of the utility functions. Another example: gsap.matchMedia() is insanely powerful but it requires some very deep hooks into the core that affect a lot of little pieces, so it's just not feasible to pull that out into its own little modular chunk unless we degraded performance by adding a bunch of little optional hooks and callbacks elsewhere in the core to bolt in the logic in the rights spots. It just made a lot more sense to bundle that functionality in the core. Better performance, and overall less file size as a whole. Performance or file size can sometimes be improved by reusing internal variables and chunks. So if they're all busted apart into their own little independent modules and then you try to put them together, you may end up with a larger file size because of the redundancies. For example, a lot of the easing functions are dynamically built using some helper functions that piece them all together. If they were all separated out, they'd each be bigger independently. Merging them results in overall file size savings if you're using more than a couple of them. It'd require a BIG change to the API. Again, you couldn't just rely on gsap.to(), gsap.from(), gsap.timeline(), etc. - we'd have to create little independent exports like Tween, Timeline, etc. that you'd import which may work well for build tools but then what about people who load GSAP over a CDN? We could try to put the most common things into a "gsap" object, but again, the overall size would likely be larger for that and then it'd get more clunky API-wise because the code itself would look different if you're using a bundler/ES Modules vs doing a standard <script> load from a CDN (like Tween(...) instead of gsap.to(...)). Historically, we've put a huge priority on consistency and ease of use. It goes counter to that if ES Module code looks different than UMD code. A lot of people have invested time into learning GSAP over the years and feel comfortable with the API, so switching things up like this could be quite jarring. Developers often think of file size in a way that's not very helpful or accurate. They simplify it to "bigger is always worse", but forget about caching or runtime performance tradeoffs or code clarity/portability/compatibility. They're quick to sacrifice all that other stuff in order to gain an average of maybe 10ms extra up-front load time...ONCE in their entire app/site. Even if it means their runtime animations bog down in the browser or their code can't be used in various other contexts. It becomes all about the initial file size hit rather than more of a holistic approach that considers all those other factors. We've already taken a modular approach in terms of GSAP "plugins". The features we deemed critical, we put into the core and then we wrap less commonly used features in plugins. That keeps file size down. I know it's easy for other newer libraries to tout small file size as a benefit to try to appear "better" than GSAP. And I have nothing against any of the other libraries in particular - use them if you like, but beware of the tradeoffs because they'll rarely mention them and we try not to talk too much about them because we don't want to seem like we're insulting the hard work of other library authors. Another way of looking at it: would you rather spend an extra 8ms (or whatever tiny fraction of a second it'd take to load GSAP by your average user) once on the initial load for an entire site and get all the rich benefits of GSAP including all the functionality and runtime performance or sacrifice that for the difference in load time that virtually nobody would notice? All that being said, we'll certainly be looking for ways to increase modularity and minimize file size in future releases. ✅ And again, it was an excellent question. Thanks for giving me a chance to blabber on about it a little bit.

Oh, I see. Well, honestly I'm on the fence about that because as a user, I absolutely HATE when websites lock the scroll like that. I can see the scrollbar and I know there's more content to get to...but I'm forcibly prevented from getting to it. Very confusing. Makes me wonder if the browser froze or there's a problem with my device. So adding a helper function like that to the official docs makes me feel a little gross, like I'm actively helping more people do that. I'll ponder it. Especially if more people ask for it, perhaps I should get over my personal issue with it. 😬

This is the key: end: () => "+=" + (large.offsetHeight - window.innerHeight), That makes the pinning distance correspond to the overflow/height of the content. More content would mean a bigger number there, so it stays pinned longer. And I added conditional logic to skip the whole thing if the content is too short (no overflow). Does that clear things up?

Here's how I'd probably do it - just add a data-nav-colors attribute to the sections you want to affect the nav colors, and put a comma-delimited list of the colors (backgroundColor, then color): https://codepen.io/GreenSock/pen/YzdYdzK?editors=0010 There are a lot of ways you could do it. Hopefully this gets you on your way. Happy tweening!

Are you trying to accomplish something like this?: https://codepen.io/GreenSock/pen/xxmpQwP?editors=1010

@IndM could you elaborate on exactly what you wanted to add to that page?

That's because it you wheel strongly enough, the native scroll could jump so far that it actually spans across MULTIPLE sections (like if each section is 100px high, and the wheel event's deltaY is 300 for example). So you just need to build in logic for cases like that: https://codepen.io/GreenSock/pen/eYbyWbd?editors=0010 Better?