Grene
Content Type
Profiles
Forums
Store
Blog
Product
Showcase
FAQ
Downloads
Posts posted by 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!
-
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?
-
7 hours ago, Toso said:
hi @Grene usually it happens cuz of the browser, I get the same issue with Safari every time but usually, I use anticipatePin: 1 along with ScrollTrigger.normalizeScroll(true) and it fixes it
so try to add both of them and create a demo if this didn't work for you so we can test it and find a way around it
Good tip, thank you!
6 hours ago, GreenSock said:That's a good catch, @Grene. When checking the code, it does anticipate in the down direction, not up. That should be resolved in the next release which you can preview at https://assets.codepen.io/16327/ScrollTrigger.min.js (you may need to clear your cache).
Better?
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.
-
1
-
-
26 minutes ago, mvaneijgen said:
It is probably scroll-behavior: smooth; that Bootstrap adds to something like the body or the html. Try setting scroll-behavior: auto !important;
Hope it helps and happy tweening!
See the Pen PoLZQrv by grene (@grene) on CodePen
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!
-
10 hours ago, GreenSock said:
I don't notice any glaring errors, no. And I cannot reproduce the problem you described at all. I tried in Chrome a bunch of times. I scrolled down to the bottom in a page that is NOT inside an iframe (CodePen debug mode), then refreshed. Worked perfectly every single time. Is there a secret to getting it to break? Are you using the latest version of GSAP/ScrollTrigger?
It's just super difficult to troubleshoot when we can't even reproduce the problem at all. 🤷♂️
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.
See the Pen abMdqLp by grene (@grene) on CodePen
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!
-
40 minutes ago, Grene said:
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.
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.
-
1 hour ago, GreenSock said:
Welcome to the forums, @Grene!
I don't have time to dig deeply into that right now, but this definitely looks like an issue with the way you're setting everything up CSS-wise.
Basically, the markers are "propping open" your container; you shouldn't be relying on them to do that. You're literally changing the positioning of elements inside the scroller so that when they're active they jump to a totally different "top" value which could alter how tall the container is (how much scrollable area there is).
Why are you using a <div> as the scroller instead of the body? It's fine to do that, I'm just curious. You're ending up with a <body> that has a scrollbar AND a child element (your scroller) that has ANOTHER vertical scrollbar. It just seems very confusing and convoluted to me, fraught with CSS/layout-related "gotchas". And all your JS is waaaaay too verbose and repetitive.
Imagine you've got an 800px container with contents that are 1000px tall, thus it can scroll 200px total. Then you create a ScrollTrigger with start: 500 which means it'll start when the scroll position is 500...but you only have 200px max to scroll, so you'll NEVER hit that! But if you enable markers, it'll drop a marker at that spot...which is another <div>, thus it props open your container so that now it can technically scroll to 500px, but only if you enable markers. This is NOT a bug in ScrollTrigger. It's just a logical consequence of enabling markers. The REAL problem is how you set up your page where it's impossible to ever reach that scroll position that you're setting up your triggers to trigger at.
See what I mean?
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.
ScrollTriggers are positioned wrong after orientation change
in GSAP
Posted
Good evening!
I've made this scrollytelling script (I call it a "labelroll"), with scrolling cards ("labels") in front of sticky, full-screen backgrounds that fade into view as the corresponding card enters the viewport.
I use scrolltriggers to change the opacity of the backgrounds based on the position of the cards, and their positions seem to refresh correctly when resizing the window. However, when changing the orientation of a phone back and forth, they're being positioned wrong.
The same behavior occurs when using the rotate button in the device toolbar of Chrome's DevTools.
Here's a video illustrating the issue using the included CodePen in debug mode: https://streamable.com/i41sbd.
There's two labelrolls in the pen, hence why the first set of backgrounds become unsticked halfway down the page and everything scrolls before the second set sticks. (Please ignore the wrong "labelroll" number on the second set of labels in the video.)
I've attempted to solve the issue manually by using ScrollTrigger.refresh() together with a listener for the ScreenOrientation change event. This unfortunately did not work.
See the Pen bGydNMv by grene (@grene) on CodePen