akapowl

Hello @Stahlpruegel - welcome to the wonderful world of GSAP and the forum! It's really hard to tell how to help, without a minimal demo - things really depend on the scenario your code snippet takes place in. Scrollbars will get added whenever you have/add more space than is visibly available in either the container of an element or the viewport and thus overflowing it. So maybe a quick fix could be to just set overflow to hidden on the container your icons are in - maybe that is not possible though because it would break the effect you are after - see the problem? ...we can't really give solid advice without knowing your setup. This is how you could rewrite it to a timeline instead - the only changes on the tweens is that the second one now does not have a delay property anymore here, but the 'delay' is being handled in the position parameter. And I changed the ease to use the new syntax. [Don't mind the delay on the timeline itself - that's just to make sure things don't start tweening too early here] https://codepen.io/akapowl/pen/xxWRaWR

Hello @Kane That is the case because you are trying to mix two different default behaviours into one ScrollTrigger. The default start value for non-pinning ScrollTriggers is 'top bottom' while the default start value for pinning ScrollTriggers is 'top top'. So if you just set pin to true on that one ST you have there, it will by default start when the trigger element's top hits the top of the viewport instead of when its top passed the bottom of the viewport if you didn't set pin to true - does that make sense? Suggestion: Just set up a second ScrollTrigger for the pinning for however long you want to pin your navbar. I set the end to 'max' here so it will stay pinned throughout the rest of the page - if you use a different value for this, like e.g. "+=500px" you will probably also have to set pinSpacing to false. Some sidenotes: toggleActions and scrub do not work side by side - either one or the other can control the tl/tween - if you have both set, the scrub will always win. And if you only have one tween (which of course might not be the case in your actual project but only just for this demo) there is no need to use a tl. I hope this will help. Happy tweening and welcome to the GSAP forum! https://codepen.io/akapowl/pen/YzapqBo

Hello @Arunkrs If you are using locomotive-scroll for smooth-scrolling and barba.js for page-transitions, and your problem is that your website doesn't scroll anymore after a page-pransition, this really does not sound like a GSAP issue at all but more like logic-issues with regard to locomotive-scroll and barba.js. We love helping with GSAP-related questions, but unfortunately we just don't have the resources to provide free general consulting or logic troubleshooting - especially with regard to different 3rd party libraries. Of course anyone else is welcome to post an answer if they'd like - we just want to manage expectations. You will probably have to make sure to either properly update your locomotive-scroll instance after the transition or to destroy the instance on the old page on leave and create a fresh instance on enter of the new page - there are different approaches to that, depending on how exactly you have things set up. But again; I really don't think that is in any way related to GSAP. There is a section in the barba docs for how to handle 3rd party scripts - it even has a part dedicated to locomotive-scroll suggesting how to handle things with smooth-scrolling libraries as such - I would suggest starting there. Happy tweening! https://barba.js.org/docs/advanced/third-party/

I'm on Windows and I can see the gradient with both approaches just fine in every major browser. My best guess is that you are viewing this on Safari, which does have quite a lot of quirks with regard to scenarios like these ( gradients on text or in general ) if I recall correctly. This really is more of a general CSS / browser related issue and not a problem with regard to GSAP. You have to go with however browsers work - and for being able to transform spans (which is what the data-lag essentially does behind the scenes) you will need to change their display property because tranforms don't work on inline elements (unless they are in a flex container apparently). So if you need the gradient text to be working across browsers 100%, you will need to find a setup that allows for that with keeping in mind that you also need transforms to be working on your elements, which I can not work out for you, I'm afraid. Here's a pen just showing that transforms don't work on inline elements. https://codepen.io/akapowl/pen/dympovr

Hello @Praneet Dixit This is probably a CSS issue, related to the spans being display: inline by default. As it works 'properly' inside the flex container without the h1 wrapping the spans, one option would be to set the h1 to display: flex too. But probably it would be safer to just set the spans to something like display: inline-block instead. https://codepen.io/akapowl/pen/RwMGNGy

Maybe this can help give you an idea for how to approach something like that with the Observer Plugin.

Also, the CSSRulePlugin was intended to make it possible to animate the CSS rules of pseudo-elements way before there were CSS-variables. Nowadays you might be way better off animating those instead - as it also says in the header of the docs page Maybe this will make it easier for you - welcome to the GSAP forum!

Hello @Rio I'm not 100% sure I fully understand what you mean, but from what I can tell, it really shouldn't / doesn't do add up the value - it would only do that if you used a relative value like "+=30" - if I am not missing something, the code you posted should actually always tween it to 30 - unless you maybe have the initial transforms set on a different element, like a child e.g. but then you tween on the parent. Minimal demos say more than a thousand words, and since you might either mean, do or want something totally different than what is shown in my example (click the body repeatedly to see it always tween to 45), a minimal demo of your scenario would be really appreciated for us to provide you with the best advice possible. https://codepen.io/akapowl/pen/poLgGZQ

Hello there, Lee - welcome to the GSAP forum. Since you've already set the different tweens in your timeline to start simultaneously at the beginning of that timeline, just adjust the durations of the tweens, to fit your needs. E.g. set the tween that is supposed to be scrubbed through the whole 500 pixels to duration: 1 and the tween that is supposed to tween through only the first 250 pixels to duration: 0.5 Here's how durations work with scrubbing ScrollTriggers: https://greensock.com/docs/v3/Plugins/ScrollTrigger#scrub I hope that will help. If it doesn't, a minimal demo of yours would be greatly appreciated!

Welcome to the GSAP forum! I'm not sure I fully understand the exact behaviour you are aiming for, but this sounds a lot like what was handled in this older thread. Here's a direct link to the helper function crafted by @GreenSock, posted within that thread. I hope that will help. Happy tweening!

On mobile Safari only? ...sorry, but I can't help with that.

Hey @Ryan Lee I added a google translation to your posts, as these forums try to keep things in English, so others who can not speak your language can benefit from this thread, too. If you can, please stick to English in future @noviedo' suggestion is great - but if you know exactly when you add new things to the DOM and it doesn't happen in dozens of different places in your code, a simple specific ScrollTrigger.refresh() after the new content was added would be enough - like at the end of your click event e.g. Happy tweening!

Yes, both do animations. TweenLite is just an older version. Before GSAP3, which uses the gsap.to() syntax, there were different 'packages' like TweenLite, TweenMax, TimelineLite and TimelineMax, that had different feature-sets with different file-sizes, so you could choose a smaller 'package' if you didn't need all of the features and wanted to save some kb. That changed with GSAP3 - it now has all the features in the core and was optimized with regard to the kb quite a bit. If you don't depend on older versions because they are deeply rooted in older projects of yours, it's always best to use the latest version. Here's a link to the migration guide, in case you want to update some of those cases you saw in the videos to the newer syntax. Welcome to the GSAP forum, happy learning and happy tweening!

Hello! Unfortunately that is not a very good description of what the problem is you are encountering. My best guess is that you just need to set overflow-x to hidden not only on the body but also to the fake-horizontal .section as also described in the thread linked below. If that does not solve what is not working for you, please describe your issue in a bit more detail and I'll see if I can help. Thanks! https://codepen.io/akapowl/pen/VwQEGNy

Welcome to the GSAP forum, Chris! The messier your code, the longer it will take for people helping to even get to the point to know how they can possibly help. While it is quick for you, it will not make things quicker for us - and we will have to do the extra work to make sure things display properly in the first place - like your nav. So the time it takes will be the same in the end, maybe even longer because we are not familiar with your project like you are. Also, if there is lots of images not loading that actually do in your actual project, some things we suggest might not even work out properly, because the dimensions of the images might matter depending on the scenario. So it is always best (even just out of courtesy to those you ask for help) to provide a demo as clean and minimal as possible. With regard to your actual question: The way you are handling things with your ScrollTriggers, you are triggering an animation to fade the headers color in and an animation to fade it out at the exact same point in scroll - see the problem? You can create just one tween attached to one ScrollTrigger and define how that tween should be controlled by ScrollTrigger via toggleActions. toggleActions String - Determines how the linked animation is controlled at the 4 distinct toggle places - onEnter, onLeave, onEnterBack, and onLeaveBack, in that order. The default is play none none none. So toggleActions: "play pause resume reset" will play the animation when entering, pause it when leaving, resume it when entering again backwards, and reset (rewind back to the beginning) when scrolling all the way back past the beginning. You can use any of the following keywords for each action: "play", "pause", "resume", "reset", "restart", "complete", "reverse", and "none". If you want the tween to start playing once that sticky part at the bottom starts scrolling with the flow, you'll also want to re-consider the start of your ScrollTrigger. It looses its stickyness when the bottom of the carousel-wrapper hits the bottom of the viewport - so instead of 'top bottom' it would actually be 'bottom bottom' - the first parameter is related to the trigger element, the second to the viewport. If you then set the toggleActions to "play none none reverse", it will play the tween onEnter of the ScrollTrigger - i.e. when the bottom of the trigger element hits the bottom of the window when you are scrolling down - and it will reverse the tween back to the transparent color onLeaveBack, so at that exact same point but when you scroll back up again Like this. Is that what you had in mind? https://codepen.io/akapowl/pen/WNzvQVj

Yes ... just like you have to remove e.g. any eventListeners you created, you should defnitely do that - not only to make sure everything will run as expected, but also because you may be creating serious memory leaks if you don't and things pile up. This here is just a very basic example logging out a number - not that it gets dangerously close to crashing your computer or something - but just imagine things piling up like that with many more ScrollTriggers on a page and some of them doing some complex stuff onUpdate e.g. https://codesandbox.io/s/h59k6h?file=/src/index.js It does make sense, but I think it also sort of depends. I tinkered around with barba in combination with scroll-smoother myself a bit in the meantime and I had my barba-container wrapped by the smooth-content and smooth-wrapper just like you have, when doing so. I actually got to (only) recalculate the scroll height just fine by calling a ScrollTrigger.refresh() after a transition - which does not appear do to the trick alone in your example - not sure why though, maybe I just missed something in a hurry here. But creating a new ScrollSmoother is something I would definitely recommend anyway though, because if you e.g. use ScrollSmoother's built-in effects, it will probably not know about the new elements on the page (but still target the old elements that aren't there anymore) if you don't - at least I couldn't get it to work after a transition, if I didn't re-create ScrollSmoother on the new page after the transition but solely called a refresh. I would also suggest specifically killing the old ScrollSmoother instance as well when you leave a page - it looks like there will be only one instance on the page anyway, because ScrollSmoother probably is clever enough to manage itself there when another instance is created, but it shouldn't hurt to kill it and doing so might prevent possible problems you may run into later on - and it could become tricky to find what's causing them then. FYI - both hooks you use for the creation of ScrollSmoother fire on first page load - so technically there isn't actually the need to also put the creation it in the once hook. Which hooks fire when is something you should consider diving deeper into when using barba, as it might also create problems at some point if you call something multiple times that is supposed to be fired explicitely only once e.g. Another barba "thing" is that the current and next container will be in the DOM for a certain amount of time during the transition lifecycle, so if you create new ScrollTriggers while that is the case, they will/might not have their starts and ends where you would expect them to be. So if you don't use synced transitions with barba, it would be best to manually remove the current container at a point when it's safe to do so - before creating STs. And now in hindsight, I realize that this is also the reason, why I couldn't get to recalculate the scroll height properly with a simple refresh call as mentioned before - because earlier I had forgotten to do that 🤷‍♂️ I'll stop right here, because these are the GSAP forums after all - but those should also be the most relevant points - I hope this will help a bit.

On codepen only - but usually when something runs smooth on codepen, but not on your website, it's something else on your website causing issues.

What website?

I see what you mean, but we can not debug live-websites, it's just not feasible - there is too much involved outside of GSAP/ScrollTrigger that could be causing your problems. The best suggestion I can give you right now is to narrow down things by stripping down bit by bit until the point where it runs smoothly - and then add things back to see at which point it becomes problematic.

It's perfectly smooth for me - but I might be misunderstanding what it is you mean by that, so maybe it can help if you could elaborate a bit.

This was asked twice before in the past couple of days. I was under the impression, that the post with a suggestion by @GreenSock, I linked in those other threads might be helpful with that regard, but I might have been a bit quick with that assumption, as that suggestion looks to actually be with regard to another, a bit different, problem. I think the problem here actually is that with trackpads, as well as on mobile devices, the scrolling works a bit different than it does in destkop browsers - when you flick the trackpad or the mobile device's touch screen, the scrolling will smoothen out over time. Now because of this, the browser might still be technically scrolling / smoothening out the scroll / firing the scroll event even after one tween to the next section would be finished, so it would trigger the next tween to the next section because of that. An approach to prevent that from happening might be to somehow intercept this for the animation not to be triggered multiple times then. But after quite a bit of tinkering, I'm not sure if that is even possible. I've tried with this code posted by @OSUBlake, which probably is the most complete approach to that goToSection ScrollTrigger/ScrolToPlugin technique that is around this forum, and does appear to already have an approach of disabling the scroll while moving to the next section and after arriving re-enabling it again - but even with that it doesn't prevent triggering the next tween when flicking the trackpad/mobile screen quickly enough. I tinkered with other methods too, but with nothing I tried, I could get it to prevent this from happening, which sort of leads me to the conclusion that you can not really have control over this - but of course I might as well be totally wrong with that assumption. From what I understand; while you can prevent the events from firing that would trigger the scroll (like touch events or the wheel event), you can not really intercept/stop the scroll event itself from firing, which I imagine would probably be neccessary in this case. Just an example of what I mean - flick your trackpad real hard in this demo and then click once to disable the page being able to scroll, here by setting its height to 100vh and additionaly overflow to hidden. Now since the page wouldn't be able to scroll anymore, one might assume, the scroll-event might have been intercepted - but actually, if you click a second time quickly enough, you will notice that in the background, things kept going, and the smoothening out of the scroll will continue happening when the page is able to be scrolled again after the second click. Unfortunately, I couldn't find any real solid information on this, trying to search for this - so this is just a theory / assumption of mine for now 🤷‍♂️ Probably one the of many reasons why scroll-jacking like this is not feasible to implement on top of native browser scrolling. Although I personally am no fan of that approach to begin with, it would still be interesting to know if I was somewhat right with the assumption that it is not possible to intercept this, or if I may be just missing something obvious here. https://codepen.io/akapowl/pen/ZExGzLE

Hello there and welcome to the GSAP forum! That is the case because you are creating the STs to toggle the class before you create the ST that pins the first section - so at the time you created all those toggleClass STs, their positions were right - but they can not know ahead of time about you pinning that first section later on in your code, which adds a pinSpacer and thus shifts all the positions of the elements related to the subsequent ScrollTriggers) That is why the positions of the subsequent STs will not be where you'd want them to be in the end. It's best to always try and create your STs in order of appearance on the page. If you can't because e.g. it might be more conveniant to create your STs in loops like you do here, you'll want to have a look at the .sort() method and/or refreshPriority - explanations on the latter are to be found on that .sort() docs-page or in the general ScrollTigger documentation Simple suggestion to work around your problem: call ScrollTrigger.sort() after you created all your STs. That should already help in this scenario. https://codepen.io/akapowl/pen/yLKyoqZ

Hello Anita, welcome to the GreenSock forums. I don't think you will be able to do something like that with GSAP and DOM elements alone. SVG, like in that pen you posted may be a good approach, but also it may become a bit heavy perfomance-wise in some scenarios. While GSAP can be helpful with animating just about anything, it is not made for the creation of an effect like that in the first place. It will require quite the setup outside of GSAP to achieve something like that, which we can not really help with - but of course anyone else is welcome to post an answer if they'd like - we just want to manage expectations. Your best bet will most likely be some sort of WebGL - but it will probably also not be that easy - as you might have to get familiar with shaders etc. I think on that website they use Pixi.js, but you could also maybe have a look at curtains.js or three.js. A good starting point for effects like these always is the #webgl tag on codrops or their search, where you can find a couple of similar effects, alongside tutorials in many cases, that might be helpful to get you closer to the effect you want to achieve. I hope this will help a bit. Happy tweening!

Hello @amort2000 In general, it is pretty tough to give solid advice without a minimal demo - but I think you'll just need to delay the change of the window.location.href - maybe put it in an onReverseComplete callback - similar to what was shown in the example in the thread linked below. If that doesn't help, a minimal demo of yours would be greatly appreciated.

Yeah, I understand. Nice thinking! You can always try that yourself Looks like when you set the stroke-width of the mask path to just wide enough to not look weird when tweening around the corners but also not reveal some parts of the path when getting scaled down too much, you could pull it off. Maybe one of our SVG-Gurus even knows of a better approach for this - but this looks to be working quite alright https://codepen.io/akapowl/pen/YzazqMg