akapowl

@ZachSaucier is totally right. I was thinking of it wrong. You actually do apply the triggers in the right order of appearance on screen. Sorry for the confusion @Tom Kochi

Hey @Tom Kochi That might be because - judging from the values you use - the first Trigger you create should happen after the second one but in your code is being applied before the second one, so the values are not being set correct. If you simply just apply the second trigger before the first, you'll see, it works. https://codepen.io/akapowl/pen/558e78b1a611795fd66b3cc47ab3c743 You could probably also use refreshPriority but it's best to create ScrollTriggers in the order they'd happen on the page. refreshPriority number - it's VERY unlikely that you'd need to define a refreshPriority as long as you create your ScrollTriggers in the order they'd happen on the page (top-to-bottom or left-to-right)...which we strongly recommend doing. Otherwise, use refreshPriority to influence the order in which ScrollTriggers get refreshed to ensure that the pinning distance gets added to the start/end values of subsequent ScrollTriggers further down the page (that's why order matters). See the sort() method for details. A ScrollTrigger with refreshPriority: 1 will get refreshed earlier than one with refreshPriority: 0 (the default). You're welcome to use negative numbers too, and you can assign the same number to multiple ScrollTriggers. Check the docs for more info: https://greensock.com/docs/v3/Plugins/ScrollTrigger Cheers. Paul

On Chrome only the window.innerHeight changes. When first swiping down a bit, so the browser-bar disappears and the resize happens and THEN swiping furhter down to the point where the circle should stick, it sticks as you'd expect. But when swiping down immediately to the point where the circle should stick, it doesn't stick but sort of hovers below the headline and pans with the scroll (sort of like the behaviour when resizing on desktop - see below for that) and then jumps into place after the resize happened. On the Samsung browser (where both values change) when scrolling to the point immediately the circle will 'stick' above the headline and after the resize jump into place. But when first swiping down a bit, letting the resize happen, and then scrolling to the point, it will not really stick at all but have that paralax-pan-feel (sort of like the behaviour when resizing on desktop - see below for that) - it will jump down after the resize but not in place with the headline but instead below it - and it keeps the paralax-pan-feel. Unfortunately, I can not see any consistency there... There is just too many possibile scenarios with different outcomes. Another thing I noticed though, is, that on desktop, when you resize the window, the circle wont really stick to the headline anymore either - it will sort of 'pan' above it in a paralax sort of way. So, I think, there really might be more than one problem occuring at the same time.

Samsung Internet on Android 10 - Galaxy Note 10: Both values change when browser bar dissapears. It definitely does on some browsers - others behave differently. This has been an issue ever since vh-units have been introduced I think. I have tried finding a way around this myself for a veeeeeery long time - and the only 'solution' - more like a workaround with caveats - I found for myself, was preventing the browser from removing its navbars on scroll altogether. There's an interesting attempt to tackling that issue over on CSS-Tricks: https://css-tricks.com/the-trick-to-viewport-units-on-mobile/ ( written by @Mamboleoo if I am not mistaken ) ...and another one here: https://allthingssmitty.com/2020/05/11/css-fix-for-100vh-in-mobile-webkit/ ...for furhter reading on that topic, I also recommend the following: https://nicolas-hoizey.com/articles/2015/02/18/viewport-height-is-taller-than-the-visible-part-of-the-document-in-some-mobile-browsers/

Hey @crawlers I was basically just about to say the same as @ZachSaucier I think the effect on that website is created with the help of Pixi.js - but you could also use other libraries for that, like three.js. If you wanna learn more about how to get there, you could check out this neat tutorial on Codrops on how to creat similar effects with three.js. https://tympanus.net/codrops/2019/10/23/making-gooey-image-hover-effects-with-three-js/ Cheers.

Don't know if I understood the problem correctly... But might this be related to using vh-related values for certain elements? I remember @OSUblake posting in a different thread, that "100vh might not be what you think in mobile" with a link to this page: https://github.com/bokand/URLBarSizing Since the v(iewport)h(eight) changes when the browser built-in navbar appears/disappears (different handling on each mobile browser) the elements get repositioned respecting those new values which might be causing the jumps you refer to.

Not Chrome - but still Chromium - Opera actually. Yup, you're right. Without GSDevTools it's running. The demo in the link you provided, however, runs as intended - with or without GSDevTools. 🤔 https://codepen.io/GreenSock/pen/PooWQdb

Since I was about to say the same and give a link to the v3 Docs for this (😉), I noticed, that the demo in the docs is not running properly (at least on my end) , @ZachSaucier https://greensock.com/docs/v3/Plugins/Physics2DPlugin https://codepen.io/GreenSock/pen/emjgxw

Caught me on that one, @ZachSaucier 😄

@Avargas That is absolutely possible with the same timeline. As @Richard1604 mentioned there is the nifty .addPause() method for timelines. You could simply just throw it in after your first two tweens, add an eventlistener for the click-event onComplete of your second tween and run a timeline.resume() when that chosen element is clicked. Adjust the timing for your third tween, so it doesn't start two seconds late, et voilá: Your timeline resumes on click. https://codepen.io/akapowl/pen/6dc677cca42d34d2d20b3e589f94e4c2 Check the docs for more information and all the other beautiful stuff that GSAP gives to control your animations with ease. https://greensock.com/docs/v2/TimelineMax/addPause()

Aw man, @PointC, you just beat me there by seconds. Was about to suggest the same. three.js came to my mind instantly, too, when reading this. @cworf Check how smooth it is. You could set up a scene with your SVG and just animate the camera rotation. Not SVGs used in the following example (I think), just for example of its smoothness: https://threejs.org/examples/#webgl_interactive_raycasting_points

Here is a suggested solution with the use of smooth-scrollbar (see bottom of this post) @karaulovskin The thing with smooth-scrolling libraries, like smooth-scrollbar (don't know about ASScroll - but from what I have read somewhere in this forum, I think it might be easier to handle) is, that they pretty much change everything about the browser-implemented scrolling. That means that you really have to try understanding what they do and how they handle things - otherwise you will run into problems with scroll-based-animations over and over again with no idea how to tackle them. And most of those problems will NOT be related to GSAP or ScrollTrigger at all - just to the way the browser-scrolling is being changed by those libraries. That's why I suggested you dig into how smooth-scrollbar operates and needs to be set-up in the first place. These are the Greensock-Forums after all, and although they truly are SuperHeroes over here, they can't know everything about every JS-Library or plugin out there. Hope the provided example is helpful and makes things bit clearer. Cheers. EDIT: Had a pen up, that showed the example with smooth-scrollbar. But somehow it only worked as intended in debug view with full-window, so I took it down for now - Don't want to spread any confusion EDIT 2: This should be working fine now: https://codepen.io/akapowl/pen/90d2b1ad119fae2d090d050276451896

I was about to say 'nay' but I forgot, I had to clear my cache. Definitely works now. Good Job! And since I too might be using this soon, first and foremost: thank you!

Hey @karaulovskin Actually, you are not quite doing as what the example shows. First things first: Your body has to be styled a certain way for smooth-scrollbar to work on the page. That is what makes the scroll "break" - actually not "appear" at all - in your example. Secondly: You don't even use ScrollTrigger's .scrollerProxy in your pen. This part is totally missing in your code: ScrollTrigger.scrollerProxy("body", { scrollTop(value) { if (arguments.length) { bodyScrollBar.scrollTop = value; } return bodyScrollBar.scrollTop; } }); bodyScrollBar.addListener(ScrollTrigger.update); It tells ScrollTrigger to work with the values of smooth-scrollbar plugin so it is rather important if you want to make ScrollTrigger work with a smooth-scrolling script like smooth-scrollbar. Lastly: It is a little tricky to guess what exactly you want to achieve. Maybe make a demo of the exact effect you want to get without the use of smooth-scrollbar first. I think that would make it easier for others to help you. I made a fork of your pen, that does most likely not show the effect you want to achieve, but it shows how smooth-scrollbar works, and how to use ScrollTrigger's .scrollerProxy in the first-place, to make ScrollTrigger react to smooth-scrollbar's 'scrolling'. https://codepen.io/akapowl/pen/6f3f9bb9052263468f90f18a0687ccdb Since this is rather complex in total, I suggest you dig into learning how to properly set up idiotwu's smooth-scrollbar first: https://idiotwu.github.io/smooth-scrollbar/ and then you dig into how to integrate it properly with GSAP's ScrollTrigger via .scrollerProxy: https://greensock.com/docs/v3/Plugins/ScrollTrigger/static.scrollerProxy() Cheers, Paul [ EDIT: Exchanged codepen-link - now links the pen itself instead of the debug view ]

Just something I noticed: If you test it the other way around, you'll notice, that the ScrollTrigger keeps responding to the initially set Scroll-Orientation. Steps to reproduce: - MOBILE viewport: VERTICAL scroll -> animation works as expected- Resize window to DEKTOP - DESKTOP viewport: HORIZONTAL scroll -> Nothing - DESKTOP viewport: VERTICAL scroll -> Animating desktop element Feels like the 'horizontal: true/false' part is not being considered by ScrollTrigger when killing & re-initiating the triggers !?

Hey @Jamesh. If I understood correctly, what you basically want, is to refresh ScrollTrigger after the sorting/filtering animation is done? you could simply just call ScrollTrigger.refresh(); whenever you need to. I threw it into one of your functions there with a delayed-call just to make a quick pen: https://codepen.io/akapowl/pen/bcaf6fbd9073eb9747f2b1200a0b4df0 Is this what you are after? Cheers, Paul

Yes, it absolutely does solve the issues. Thank you, @GreenSock !!! I just had to add a little 'pointer-events: none' to all my pinned sections, additionaly to your suggestion, to make sure that I can still be scrolling/swiping on, when the section is fully in viewport. But now the pins appear truly pinned. And I will say that, actually I was kind of close to getting to this myself. I had tried applying the .scrollerProxy with 'pinType: "fixed' but at the same time I was giving ScrollTrigger different 'directions' via .scrollerProxy with this scrollTop(value) { if (arguments.length) { $(".full-height-container").scrollTop() = value; } return $(".full-height-container").scrollTop(); } because I was under the impression that it might be needing the scroll-values from that container. But I guess by doing that, I changed the context myself once again, so the pinType: "fixed" did not do what I was expecting it to do. So, thanks a whole lot for your help with finding a solution, but even more for your in-depth explanation, making things a bit clearer to me! Cheers

Like so then, right? https://codepen.io/akapowl/pen/d84ca98a04e21d5fcc63d0f9d5d43d3d Works like a charm! Thanks a lot @ZachSaucier

One more thing: When chaining the tweens up one after the other as tightly as that, I saw, that you will eventually still get jumps, when using scrub: 1 and scrolling too fast, because the scrubbed value is yet to be applied when the next tween already starts. So I guess, either just use scrub: true and lose that nice effect, or make sure to implement some "buffer-zones" in your markup to give it enough air to breathe, when you want to keep that nice effect, the scrub: 1 delivers. Someone please correct me if I am wrong or if there is another way to avoid that.

100% buttery smoothness in my pen now. https://codepen.io/akapowl/pen/94ebcbff6f403f34075b36738ad41c3d Also, I cleaned things up just a tiny bit to show the usage of GSAP's defaults, as @ZachSaucier hinted to. Thanks for the help and explenation @GreenSock You might wanna try this, @Tonycre8

Since I am interested in this myself, I prepared a little reduced and slightly differed scenario that basically represents what @Tonycre8 is experiencing (at least I think so). https://codepen.io/akapowl/pen/856fe178c736444b2d6e1d7b1e13bce2 When getting to the point, where a parameter (x, y or z of camera position or scene rotation), that already has been tweened, is going to be tweened again, the value where it is tweened from appears to be the value that has been set up prior to setting up the ScrollTriggers and not the value it has been tweened to before. In this case: scene.rotation.set(0, 1.88, 0) camera.position.set(2, 0, 5) I hope that is somewhat understandable. Interestingly enough though, I found, that if you scroll to the bottom of the page and refresh the page, the animation seems to run as probably intended by OP - in both directions, scrolling up and down.

That makes total sense. Thanks @ZachSaucier "Can not have" might have been a bit strong - Actually, I totally could. It is part of preventing the browser-built-in navigation-bars to disappear on scroll/swipe on mobile devices. You know how working with viewheight based values can be a pain sometimes in regard to mobile, right? When no transition applied, elements tend to just jump into place when the browser-bars disappear/re-appear. And with regards to look and feel of a page that can be pretty disruptive in a way. I know preventing the default browser behaviour can hurt usability - don't judge me please 🙈 . Sounds like that is just due to how browsers work then!? ...sort of fits the theme here.

Hello everyone, I am slowly getting the feeling, that I am severely miss-using ScrollTrigger, and by now I am feeling pretty bad for always bothering you guys. I have tried about everything that came to my mind and still can't wrap my head around this. I know this might be a bit much to process, but I'll ask anyways. Maybe someone finds the time to help me dig into this. As several times before, there is that thing with the horizontal translation of the content in a section when scrolling vertically. Everything is working just wonderfully, when the body is the scroller, just like in this pen: https://codepen.io/akapowl/pen/8a383f202ba53d6b11cc83da39b6f5b5 But I have this scenario, where I can not have the body be the scroller. So I set the body to overflow: hidden and a div inside the body to be the element that is being scrolled instead. When doing that, the pins did not seem to work the way they worked before and went all wonky, which can be seen here: https://codepen.io/akapowl/pen/0a02364ff4521d80fc2b80ce5430fdbb I thought, that might have to do with me pinning the wraps inside of the sections, instead of the sections themselves, so I tried pinning the sections themselves instead, which resulted in this: https://codepen.io/akapowl/pen/b1b41b5f9203d9d95c8e63feff479312 At first glance, the pins appear to be working correctly, but especially on mobile you can see, that the somewhat "lag behind" - don't know how else to describe it - depending on speed and direction they tend to be pushed up/down in scrolling direction. I thought this might be a case for reparenting the pin but it didn't work. Additionaly to that, the different sections sections don't seem to have the correct background-color applied to them anymore. So to finish things up, I guess my questions are: Am I doing something horribly wrong here? (Like; am I preventing ScrollTrigger to get the right values for it to be working properly?) Is this sort of scenario to be avoided in the first place, when working with ScrollTrigger? And/or might there be a work-around for me to get the same behaviour as in the first of those three pens, where the body is the scroller? Sorry for the long post 🙈 Cheers, Paul

Good to hear you got it working And yes. The part with data.current.container.remove(); is another barba-related thing that needs to be done in certain scenarios like yours, because there is a timespan when both - the new and the old barba-container - are in the DOM at the same time. So you need to make sure the old stuff is gotten rid of before ScrollTrigger is being applied, so it does its' magic to the right portion of the code. Again, that is not really related to GSAP per se - just to clear things up for future readers. On a side note: I love, how you melted Zach and Jack into one person named Zack

Well, I guess that is very well more related to the way barba works, than it is a GSAP issue. You have to kill the 'old' ScrollTriggers on page transition and re-initialize them fresh on entering the new page. What worked for me was this nifty piece of code I grasped from Jack or Zach once (don't know which one of you it was) let triggers = ScrollTrigger.getAll(); triggers.forEach( trigger => { trigger.kill(); }); You will have to find the right barba-hooks for your project to kill the 'old' ScrollTriggers and re-initialize the 'new', though. Hope this helps a bit. Cheers, Paul