Grommas Dietz

Question number one and your example make perfect sense, thank you!

Working on another project I run into another scenario where it’s necessary to switch the target. After resetting the target option, the scrolling speed gets faster on each switch within my early tests. Is there already a way of solving this issue or will it be possible to change the target in future versions?

Is there a way of using limitCallbacks on a single instance of ScrollTrigger instead of using it globally inside scrolltrigger.config? In my project there is a quite simple lazyload mechanism observing videos and images. Since the user can jump directly to an anchor, I have to limit the callbacks. At the same time there is a fixed navigation with some logic which should not be affected by callback limitations.

At the first look it seems to work quite good for an isolated scroller in macOS Monterey 12.3.1 and Safari 15.4. But there are some jumps on iOS 15.4 (Safari, video attached). While working with an isolated scroller, it does not work well with multiple nested scrollers. With allowNestedScroll: true and target: ".vertical-1" it gets stuck inside the targeted scroller. When targeting .vertical-2 it is possible to scroll to the 2nd container, but we get stuck to the targeted container again as soon as we get there. Is it possible to target more than one scroller? Thank you for your investigations, really appreciate! jumping.mp4

Thanks for your thoughts! The demo I provided already shows the jittering in MacOS Safari (tested with version 15.4). Here a short video of the jittering: jittering.mp4 jittering.mp4

I already assumed that it would not be easy to solve but wanted to share it anyway. Thank you!

Hey Reinoud Adding will-change to smooth-content seems to fix the problem! #smooth-content { will-change: transform; }

I’m still fiddling around with ScrollTrigger’s brand new normalizeScroll option. I tested it on CSS native Scroll Snap. Sadly it doesn’t play nice together and ends up in jumping directly to the scroll snap points without any visual scroll. I remember there was a bug with ScrollToPlugin and CSS Scroll Snap last year which got fixed. The fix was probably quite an easy task since the CSS Snap can be turned off while scrolling to the content. Is there any chance to get the normalization on native Scroll Snap, or is it required to move completely to GSAP snapping for that? It would be great to get a hint about the restriction in the docs to be aware of the limitation.

Thank you both for the answers, looks already promising that allowNestedScroll: true makes nested scrollers scrollable again. It’s not quite what I was looking for but this option makes it much more useful in cases of native scroll-snap galleries etc. @OSUblake: I was trying to fix pinned elements inside a set of multiple scroll containers. Pinned elements jitter in safari and position: sticky did not work in that specific case. @GreenSock: Would it be possible to normalize the scroll for nested scrollers or is this blowing up the code and the performance too much? I can imagine that it’s a downgrade to always bubble up the DOM to find the active scroller. It’s kind of annoying that Safari is the main cause, but since it’s one of the major browsers it would be a great benefit.

Hey there Thanks for all your tools, the updates and new features. Really appreciate and love to work with it! Is it possible to normalize scroll on custom scrollers in future releases of ScrollTrigger? Currently the normalisation only works for the overall page, similar to ScrollSmoother, right? The CodePen provided is just a quick test in reference. Comment out ScrollTrigger.normalizeScroll(true); to see how it breaks the scrolling.

ah, that’s great, I will install the beta and give it a try! Thank you!:)

Will this be merged in the near future? I placed it in node_modules/gsap/dist manually. Not sure what’s getting picked when webpack builds my production js, but it only works in developing mode for me.

works perfectly for me, thank you!

Thank you all for your input, I will stick to my solution and disable it on touch devices. Not sure yet. Annoying, when it’s almost working.

Other animations (moving header and content) are not affected, only when the ScrollTo plugin is triggered. That’s why I thought it could be related to the plugin. Sorry if I got it wrong!