Pinning large panels in ScrollTrigger vs. other libraries

[Grene]

I'm using ScrollTrigger's pin property to create fixed images and graphics with scrolling text overlayed on top, in typical scrollytelling fashion.

 

Because I'm pinning large, 100vh/vw panels, I'm having to use the anticipatePin property to reduce the slight delay that occurs when scrolling quickly. It's difficult to fine tune this property however, because the ideal intensity of anticipatePin seems to depend on the size of the panel, and thus the viewport.

 

However, I've noticed that websites utilizing other javascript libraries to pin large panels (e.g. scrollama) don't always seem to have any of this slight delay. One example is when the graphics in this article from Science becomes pinned.

 

This is of course purely anecdotal, but I was curious to know if there's a difference in how e.g. scrollama handles pinning vs. ScrollTrigger that would explain this difference?

[GSAP Helper]

Without a minimal demo, it's very difficult to troubleshoot; the issue could be caused by CSS, markup, a third party library, a 3rd party script, etc. Would you please provide a very simple CodePen or Stackblitz that illustrates the issue? 

 

Please don't include your whole project. Just some colored <div> elements and the GSAP code is best. See if you can recreate the issue with as few dependencies as possible. Start minimal and then incrementally add code bit by bit until it breaks. Usually people solve their own issues during this process! If not, at least we have a reduced test case which greatly increases your chances of getting a relevant answer.

 

See the Pen aYYOdN by GreenSock (@GreenSock) on CodePen

that loads all the plugins. Just click "fork" at the bottom right and make your minimal demo: 

 

Using a framework/library like React, Vue, Next, etc.? 

CodePen isn't always ideal for these tools, so here are some Stackblitz starter templates that you can fork and import the gsap-trial NPM package for using any of the bonus plugins: 

• React (please read this article!)
• Next
• Svelte
• Sveltekit
• Vue
• Nuxt

 

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

[GreenSock]

Have you tried ScrollTrigger.normalizeScroll(true)? Or you could use ScrollSmoother. 

 

The fundamental problem is that most modern browsers handle scrolling on a completely different thread (not synchronized with the JavaScript thread). So imagine scrolling quickly, such that on the very next tick the page would be 100px higher. The scrolling thread says "okay, I'm gonna render the page 100px higher" (and it does so), and then a few milliseconds later, the main JS thread executes and ScrollTrigger does its thing, saying "alright, now we've passed where that element should be pinned, so let me pin it..." and now you see that element correct itself to be pinned in the proper place. It's not as if it's a bug in ScrollTrigger or anything - it's a fundamental problem with how browsers do scrolling on a different thread and pre-render those scrolling results BEFORE the JavaScript executes. 

 

So if you see a site where that doesn't happen, it's almost surely because it is PREVENTING the native scroll, and it's doing EVERYTHING (including scroll) on the main thread. It listens for wheel/touchmove events in a non-passive way and calls preventDefault() on them, and then does the actual scroll via JavaScript instead. 

 

That's what ScrollTrigger.normalizeScroll(true) does, and ScrollSmoother of course. 

[Grene]

7 hours ago, GreenSock said:

Have you tried ScrollTrigger.normalizeScroll(true)? Or you could use ScrollSmoother. 

 

The fundamental problem is that most modern browsers handle scrolling on a completely different thread (not synchronized with the JavaScript thread). So imagine scrolling quickly, such that on the very next tick the page would be 100px higher. The scrolling thread says "okay, I'm gonna render the page 100px higher" (and it does so), and then a few milliseconds later, the main JS thread executes and ScrollTrigger does its thing, saying "alright, now we've passed where that element should be pinned, so let me pin it..." and now you see that element correct itself to be pinned in the proper place. It's not as if it's a bug in ScrollTrigger or anything - it's a fundamental problem with how browsers do scrolling on a different thread and pre-render those scrolling results BEFORE the JavaScript executes. 

 

So if you see a site where that doesn't happen, it's almost surely because it is PREVENTING the native scroll, and it's doing EVERYTHING (including scroll) on the main thread. It listens for wheel/touchmove events in a non-passive way and calls preventDefault() on them, and then does the actual scroll via JavaScript instead. 

 

That's what ScrollTrigger.normalizeScroll(true) does, and ScrollSmoother of course. 

Thanks for the explanation! That makes total sense.

 

I've done some more research, and it appears that the examples I mentioned actually uses CSS and position: sticky to handle pinning (and the end of parent divs to handle unpinning). I would hazard a guess that CSS is not being handled on the same thread as Javascript?

 

Anyways, that's an interesting alternative to Javascript that I hadn't thought of!

[GreenSock]

5 minutes ago, Grene said:

I would hazard a guess that CSS is not being handled on the same thread as Javascript?

You could think of it that way, yes. But position: sticky has limitations that ScrollTrigger's pinning doesn't. If it works in your particular scenario, great! Use it.