Grene

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!

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?

Good tip, thank you! Wonderful, that looks to have smoothened things up! I'll be sure to update once the next release is out. Thank you!

Quick, general question about ScrollTrigger: Does anticipatePin work the same scrolling up as it does scrolling down? I ask because I noticed a difference when pinning large panels. Without ancitipatePin, onEnter has a small delay; however it feels relatively smooth when setting anticipatePin to 0.5. The delay seems to persists onEnterBack, though. Video for reference: https://streamable.com/yew6qx I'll happily provide a demo if this isn't expected behavior.

https://codepen.io/grene/pen/PoLZQrv Adding scroll-behavior: auto!important; to the html looks to have done the trick! Amazing, thank you! Some funny offsetting also looks to be happening to my white start markers upon resizing the window vertically, but that's probably on my start property not being a function. Woops!

Completely understandable, I should have made sure the behavior actually happens in the pen in debug mode. My mistake! I have done some more digging and realized that the difference maker is the inclusion of a Bootstrap stylesheet. I had neglected to include it in the pen because I wasn't utilizing Bootstrap yet anyways and didn't think it made a difference, but it was included in the HTML file on my computer and apparently it does. Have a look at this pen in debug mode; scroll down to the bottom and then resize the window, even by just a little bit. By doing so I'm able to reproduce the behavior every time. Reloading seems to be more random. https://codepen.io/grene/pen/abMdqLp Edit: Apparently, debug mode isn't required. Resizing the window with the pen as-is does the same.

Good evening! I'm in the process of creating a simple scrollytelling page with full-screen cards that scroll. The cards are broken up into sections where the background of the cards fade, and where one background can serve multiple grouped cards. I'm using the pin property in ScrollTrigger to have the stacked backgrounds of a section stay fixed until the next section reaches it. However, I'm experiencing some trouble upon reloading the page in Chrome while being scrolled down beyond the first section; the backgrounds of the first section appears to get stuck. The same issue occurs upon resizing the window without reloading. I have not been able to reproduce this behavior in Firefox nor Safari. I have recorded a video of the issue here: https://streamable.com/wiiyhx I'm very new to JavaScript and GSAP (thank you for making it so approachable!), so I'm probably committing more than one mistake in this pen, but I'm not able to spot what exactly is happening here. Could my CSS or template literals be causing issues with GSAP? Or maybe my logic is just no good? Thank you for any advice you may give!

Okay so, yes; without the markers, 'top' isn't relative to the top of the cards inside the scroller of the container, but rather the top border of the container. My head still struggles to wrap my head around why the markers and cards are different in that respect, when the scrolltrigger markers are literally defined by the cards, but I'll have to knead that logic some more.

Thank you! The reason I'm using a div as the scroller is because, as far as I'm aware, CSS scroll snapping only works on the window scroll of a container. But maybe I'm wrong? The reason I've used 'top' to position backgrounds 4 and 5 is to align them with their corresponding cards (cards and backgrounds are separate divs). The cards have a relative position, while the backgrounds by default are stacked on top of each other with a fixed position. I do this because most of the time, I want to fade between the backgrounds as you scroll down through the cards. It's only rarely that I want the backgrounds to stick with the cards as you scroll between them, e.g. like between card 4 and 5 in this example. By setting the position of backgrounds 4 and 5 to absolute, and positioning them at 'top: 400vh' 'top: 500vh', I'm trying to simulate how they would be positioned in the flow below background 0, 1, 2 and 3 if those didn't have fixed positions. That way backgrounds 4 and 5 align correctly with cards 4 and 5. I didn't think the markers were propping the container open because the positions of the cards are relative, so I thought the cards already were propping the container open. E.g. you can still scroll down further to card 6, which works correctly. But I'm by no means confident in the logic here 😅 And yes, the Js is way too repetitive! I've done it like this for now so that I can see and adjust everything manually, as it's my first time using Js to this extent and I'm very much experimenting.

Good evening! I'm having a first go at GSAP in an attempt to create a scrollytelling page. My goal is to have full-screen cards that scroll, but with the option of either fading or scrolling between the background image/color of each card. Previous cards will also fade out 50% as you scroll down. I'm utilizing scroll snapping so that the viewport snaps to each card. The problem I'm having is that the backgrounds of cards where the background is scrolling, as opposed to fading, breaks once I remove all markers. The linked CodePen is a working version with some markers left. Remove the markers on line 26 in the Js file to replicate my issue. The issue appears on Card 4 and 5. I also noticed that some funny things are going on with the border of the page, but that only appears in the pen. Apologies for the repetitive and not-at-all streamlined code.