akapowl

Just did 👍 Edit - For anyone wanting updates on this: Since that is not considered a regression of the fix for the original issue, it got opened as a new issue. https://issues.chromium.org/issues/332328859

Thanks! ...let's just hope they don't take it as an April Fools' Day prank.😅

@jdhadwin Hello there. While your demo is not exactly minimal, which makes it kind of hard to see through everything, on a quick glimpse I noticed, that you are trying to animate svg elements that are in <g> groups from a scale of 0, which I think is at least part of your problem - and I don't think this specifically is GSAP related. I stumbled upon this a few days ago, too - happening for me in all Chromium based browsers on Windows 11. It appears to be a bug in the chromium browser base that was already reported in September 2022 by @Cassie and later marked as solved from what I can tell reading that old bug report - but now it seems to have resurfaced. @Cassie if you find the time, could your maybe re-new that report or something like that? ... I have absolutely no clue how those work, tbh. https://issues.chromium.org/issues/40240236 These following pens don't use GSAP at all - and as you should be able to see, when elements in groups are being 'manipulated' so they start out with a scale of 0 and then changed later on, their values will get changed properly inline on the element - but the element just won't get rendered then (unless you resize the window along the process, e.g., or scroll the SVG fully out of viewport and then back into view again). https://codepen.io/akapowl/pen/vYMWZrL This will not happen with elements that are not in <g> groups, though. https://codepen.io/akapowl/pen/QWPOgzm What helped for me as a workaround was to tween from a very small scale like 0.001 instead of absolute 0. Maybe that can help you out somehow, until that issue gets resolved again. I will add, that this is just something I was able to quickly notice. If it doesn't help in your case, and you suspect that there still might be some issues with GSAP, please create a demo that is boiled down to the bare minimum but still reproduces the issue you're having, so it is easier to identify for others, what could be causing it. https://codepen.io/akapowl/pen/dyLZzyM

https://gsap.com/docs/v3/Plugins/ScrollTrigger/ It's because one of those is a tween on a ScrollTrigger with scrub: 1 - so it will take 1 second to catch up to the scroll position - and the other one is natively scrolling. So there will always be a discrepancy between the two - which will only become more apparent the faster you scroll. If you want both to behave the 'exact same', set scrub: true instead of scrub: 1 to your airpods ScrollTrigger. You'll lose the smoothness of the scrub then, of course. Or instead tween the 'over-scrolling' of the video via a ScrollTrigger that also has a numeric scrub of 1 set. But then, one way or another, you'll get a discrepancy again between that video container and the subsequent containers which would scroll natively. At this point you might end up in a 'tween everything' approach like Mitchel (@mvaneijgen) suggested in his earlier answer with the thread he linked to. An alternative to that approach could be to use overall smooth-scrolling instead, e.g. via ScrollSmoother alongside scrub: true on the airpods ScrollTrigger. Technically it's also a 'tween everything' approach - just on another level. And you'll lose some native browser features like e.g. jump-to search via F3. Is it worth the extra mile? Depends on how much you're a sucker for detail and how much the - most of the time visually small - asynchrony bothers you. Is any one better than the other? Depends on you again. Each of them has its downsides, if you ask me. Personally I'd go with the overall smooth-srolling - but that is merely a suggestion, not a recommendation by any means. It will definitely add another level of complexity with some regards. The latter - here it was just to keep track of what marker is related to which ScrollTrigger. But it can also be a helpful tool if at any point in time you might need to target any specific ScrollTrigger on your page for whatever reason logic-releated.

Then logically you'll need to make sure that your video is appearing on the page further up than it is now. You could e.g. calculate the distance it takes to scroll from when the 4s start fading out in your one ScrollTriggger until the point where your video enters the viewport now and then you'd know by how much you'd have to offset your video to the top for it to enter the viewport when the 4s start fading out. And this you'd have to of course do before you set up your ScrollTriggers for the video. Or - since your airpods Scrolltrigger is dependent on the window height anyway - just set a vh value that fits for you via CSS, e.g. via a negative margin-top on your video container. That is what I did in the codepen below. A bit of a warning though; keep in mind that since you have a numerical scrub on your airpods scrollTrigger, the scroll of the video and the fading out of the 4s will never be truly 'synced' - which will become more apparent when you scroll fast. You are adding the tweens for the fading of the video to your first timeline - which has a scrub set. I'm not sure if that is what you want to begin with, since you added the tweens at the very bottom of your JS after you created all the ScrollTriggers. And if you add it to the pinning Scrolltrigger like you do, of course it will only start fading in the opacity once the video has reached the top, and then the 'over-scrolling' you were trying to achieve wouldn't make any sense at all anymore. So you'll probably want to add the tweens to that other, non-pinning, ScrollTrigger instead and also set it to scrub. That out of the way, here's something from the article on the most common ScrollTrigger mistakes: https://gsap.com/resources/st-mistakes/#how-to-make-scrub-animations-take-longer ------ BTW - @GreenSock @Rodrigo @Cassie - there's a wrong link in that blue information box in that section of the article. It is an old URL which previously pointed to this content: https://gsap.com/docs/v3/Plugins/ScrollTrigger/#how-does-duration-work-with-scrub-true But although the general concept of how durations work with scrubbed: true is explained there, there isn't any mention of empty tweens as suggested in that blue information box - sort of confusing altogether. Edit: I also found a typo in the docs for the position parameter with regard to percentages, that I'm mentioning further down the post. Reporting it here, where it might be better to catch. ----- That second link explains how durations work with scrub: true, @newguy123 - you should have a thorough read on it to understand the concept. I added some comments in the codepen below that might help better understand it in combination with what the docs say. In that codepen I also make use of the aforementioned empty tween to create a 'gap' where nothing happens between the fading in and fading out. So I also got rid of your approach with the position parameter - of course you can do it with the position parameter, too, but you'd have to use the proper value - and for understanding how durations work with scrub: true to begin with it might be easier to work with empty tweens at first. Also, I'm pretty sure the value you use for the position parameter (i.e. "99%") again is invalid. Here's what the docs say with regard to percentage values in the position parameter. You see, a percentage value without any prefix is not listed in there. In your example you could in fact change it to "0%" and it would still behave exactly the same as it does now. https://gsap.com/resources/position-parameter/ That all said, here's the codepen. https://codepen.io/akapowl/pen/ExJNxJO

There's acctually a couple of things problematic with your example. You've got transforms apllied to the video element (which you use as the trigger and want to pin) and also to its parent element; they are likely going to mess with ScrollTrigger in some way - so unless you know exactly what you're doing I'd first go without them. Your video and its parent have a lower z-index set than the subsequent containers. So even if things would work right for you with regard to ScrollTrigger, the video would still sit on top of the subsequent containers which thus you would not get to see then until the video got unpinned. You are using an invalid value for your end. With ScrollTrigger a window's height is represented in % and not in vh. vh units are not valid with ScrollTrigger if I'm not totally mistaken. your start: "top bottom"doesn't make much sense for a pinning ScrollTrigger. If pinning something when its top hits the bottom of the viewport you will never see it getting pinned, as it is not in viewport that whole time then. If you want to trigger the video to start playing earlier, while pinning it at some different point, you'll probably have to use two different ScrollTriggers. As video elements can be a bit tricky to handle to some degree, I would suggest not pinning the video element itself but its wrapping container instead. Just set pinSpacing to false and you'll get the same effect you're after. All those things changed, you should already see something working a lot better. https://codepen.io/akapowl/pen/QWPKoPM

That is because you have a huge margin-left set on the .pinWrap via CSS which is not included in any way within the values you are currently using and you never add it to your calculations in any form. If you'd do so, it'd work just fine. I multiplied it by 2 here so basically it will end up with the same spacing on the right now when the tween is finished. https://codepen.io/akapowl/pen/zYXKbyJ

You are loading tailwind.css via the settings in the HTML section. Without tailwind, the !important statements don't matter at all, it seems. So it looks to me like it is actually more of a tailwind question; and you'll have to find out what tailwind does to your button. To be honest, asking a plumber why the lamp in your living room is flickering, might not be the best approach for seeking help. If you can not find the issue yourself, I'd suggest asking in one of tailwind's support channels, e.g. their discussion forum on GitHub. https://v1.tailwindcss.com/community https://github.com/tailwindlabs/tailwindcss/discussions

Hello there. The documentation has the answers to your questions. 1. You'll want to look for the scroller property. https://gsap.com/docs/v3/Plugins/ScrollTrigger/ 2. No, unfortunatelly it is not possible for ScrollSmoother to have it smoothen the scroll of a different element than the body. https://gsap.com/docs/v3/Plugins/ScrollSmoother/#faqs

The place it tweens to is actually not random at all in your case, but exactly what you tell it to. In your current case with feeding in an object of x:0 and y:0 to the convertCoordinates method what you will get in the end is the distance of the dragged element to your point element on both axis anytime you release - but then to your tween you're feeding those as absolute values, so it will always tween to that absolute point from the draggables origin - try getting very close to your point and you'll see that you'll end up very close to where the dragging originated. Or alternatively just log the values and compare them with the values of the transformMatrix on the element after the tween is done - logging values is a always a huge help with identifying your problems, btw. So I see two ways you could go about this: Keep the object at {x: 0, y: 0} but instead of using absolute values for your tween, use relative values like x: "+=" + point.x https://codepen.io/akapowl/pen/XWQXaLa Keep your tween at the absolute values, but instead feed an object of the current coordinates of the draggable object to the convertCoordinates method - something like {x: this.x, y: this.y} https://codepen.io/akapowl/pen/yLrezgX I will say, that since I never had the need for that method before myself, I can't give you much of a guarantee for any of the two ways to be the right way to go - and if something is inherently wrong with what I suggested, I'm sure someone with some more experience on that will pop in to help out. While version 2 to me feels like it's more in line with what the documentation says about the object you feed into the convertCoordinates method; ... after a bit of tinkering, it also feels like version 1 seems to work more reliable with quick drags and releases. In general though, both versions should work in your current case; but one might be better or worse suited for you when extending your usecase. I hope this will at least help in some way.

TLDR: At the bottom of the post you'll find an example for how you could approach it. Nonetheless, I think reading through all this can help get a better understanding. I think that would definitely be the best way to go, if you want a solid answer - because what you are asking is heavily about how three.js works to begin with. My attempt at a short answer would be: you can not easily do that in a way that it would logically work the same as e.g. changing the object.rotation.y does. And here is why (please keep in mind that I am no full-fledged expert with three.js though): While object.rotation.y (or x or z) is a 'property' of your 3D model that three.js gives you access to, you can easily set it - e.g. by tweening on it via GSAP. object.geometry.rotateY() on the other hand is a method - it is a function you can execute on that object, where internally three.js will do all the work with the value provided by you. So for starters it is not a simple value you can easily manipulate via GSAP. https://codepen.io/akapowl/pen/ZEPgYLP As you can see in the codepen above, technically of course you can tween a value you set up on an object of your own via GSAP and onUpdate of that tween call that method provided by three.js - but: a) it will not work in the same way as tweening on the object.rotation.y in the same way would - because you are only providing a value to another pipeline (i.e. the rotateY method of three) which then again does different things with it. With some trickery around the tweening on the value you sure could settle on similar behaviour - but that would really be logic for you to figure out. Just for illustration purposes, here is that same tween (albeit with different numbers) on the object.rotation.y value to show how it behaves different. https://codepen.io/akapowl/pen/vYPoNyq Now in the first pen you could e.g. get a similar effect of yoyo-ing back and forth between the two values by simply using a linear ease or an ease that goes in and out - so you see it is not impossible to achieve similar behaviour. I'm just saying that because of that extra pipeline you'll have an extra layer of abstraction and complexity added to how you'll have to approach things, which would be all yours to figure out in the process. Still I wouldn't really recommend doing that though, because... ...probably even more importantly b) You probably should not really consider doing that all that much to begin with. What three.js does under the hood of that method is to calculate the position of every single vertex of your model; as this answer on a stackoverflow post mentions: https://stackoverflow.com/questions/71506350/three-js-set-absolute-rotation-of-sphere-rather-than-cumulative-rotation#answer-71506597 That can already be taxing with simple 3D shapes, but depending on the level of detail of your model(s) this can become rather hefty rather quickly. You can certainly access and manipulate the values neccessary to do that in different ways in JS already - like e.g. by using three's BufferGeometry instead three's provided 'pre-made' geometries, but even then the calculations would be quite a bit more complex than just setting one single value somewhere. And since you say you are loading a .glb model, that will very likely not be a way to go for you anyway. Another way you could think about doing it would be to use a shader that you provide with a value you tween on via GSAP. That would probably be a whole lot better with regard to computation cost because you could outsource all the calculations based on that value to the GPU, but it would also be a whole new world you'd open up outside of JS - and the complexity of the calculations would still stand on top of that. So yeah, depending on the level of control you want to have over what you're doing, personally - with my limited knowledge about three.js - I don't think what you are aiming to do is as easy as you might think. But maybe I'm totally off track somewehere here, and the folks over in the three.js forum can provide you with some better input and an easy solution. If so, it would be great, if you'd post back here with what you found out. Good luck! ---- Edit: Alright, I played around with it a bit now, and have now stumbled upon an oversight logic-wise, that has a huge effect on how things behave. In the first example above, I am just providing the value I am tweening on to three's .rotateY method, which does cause the appearance of 'no control' because every tick I am basically telling three.js: 'add that value the tween is currently at to the rotation'. So along the tweens duration, the rotation would add up more and more and get vastly out of what I wanted it to be. An easy way to fix that is to keep track of the rotation value in an extra variable that I called oldValue in the pen below. Now in the onUpdate callback, I subtract that oldValue from the value the tween is currently at when passing it to three's .rotateY method. And after that, I set this oldValue to the value the tween is currently at. This way I can make sure that every tick only the difference between the previous tick and the current tick will get added to the rotation. And now it behaves just like the example with tweening on the object.rotation.y does. Note, that I am now also using three's built in MathUtils.degToRad, so instead of just some arbitrary values, I can work with to me far more familiar degrees instead of radians. But for the aforementioned reasons with regard to it having huge potential for killing performance, I probably still wouldn't really recommend doing that. Maybe thiss will help you out, though. https://codepen.io/akapowl/pen/qBvebOB

Why would I be lying about what I said or intentionally give you advice that I don't think will help!? 😂 Might just be me, but I think a button either works or it doesn't; not sure what you mean by 'it almost works'. The reason it sometimes works for you with opacity - and other times doesn't - is probably related to elements with an opacity of 1 having a different stacking-context than elements with any other opacity but 1, e.g. 0 or somthing in between like 0.857694857; that also pretty much correlates with what I explained in the post above; about being on scroll-positions in between. That is a browser thing - nothing related to GSAP in any other way. https://developer.mozilla.org/en-US/docs/Web/CSS/CSS_positioned_layout/Understanding_z-index/Stacking_context So when you're right on spot and an element's opacity is at 1 exactly - it will appear above all the other elements that do not have that opacity of 1 and thus it will be perfectly clickable. But if all the elements do not have an opacity of 1, they will all share the same stacking-context, and since the last element sits on top of all other elements z-wise within that stacking context, this element and no other will be clickable in those cases. Does that make sense to you?

Hello @newguy123 The most profound way to debug your code is to use the dev-tools of your browser; e.g. right-click on elements you want to inspect and see what gets selected in certain scenarios when selecting 'inspect element' from the context menu. In your case, when the scrollTo-tween is fully done, so the scrollTriggered animation is where you want it to be, your buttons will work as expeted; but when the scrollTo-tween isn't fully finished, or you are generally in a state / at a position in between, this is what will always get selected on click: I don't have the time to look through all your code in too much detail, but that likely is the case because you seem to solely rely on opacity. Opacity will only change the element visibly; that doesnt mean that items that sit above it on the z-index won't be clickable though. So you'll need to change that - a CSS property that can help you there is visibility; you'll need to also handle that for your elements. Luckily for you, GSAP has a property that combines both CSS properties (opacity and visibility) into one in a way it spares you the head-ache to figure out proper logic for that. https://gsap.com/docs/v3/GSAP/CorePlugins/CSS/#autoalpha So just exchanging opacity with autoAlpha in the tweens of the tl in your forEach loop should already help a lot with that. I hope that will help. Cheers.

Looks like Mitchel was right 👍- for that you really wouldn't need an onReverse callback. Here's just two ways you could handle something like that - and there's probably a couple others beyond those. I hope these will be helpful already, though: Depending on the index of the dot (to make sure neither the first nor the last will get toggled at the end in any direction), you could .add() functions before and after each of your tweens to toggle the class . https://gsap.com/docs/v3/GSAP/Timeline/add()/ https://codepen.io/akapowl/pen/yLwxXgX Or (even better) with similar logic with regard to the index, have things handle via GSAP altogether with .set() calls; unless you really need that active class, like maybe for something else outside of the pure styling. https://gsap.com/docs/v3/GSAP/Timeline/set() https://codepen.io/akapowl/pen/yLwxXMX Some hints with regard to syntax: // Instead of this: tl.to(dot, { rotate: "180deg" }) // You could just do this: tl.to(dot, { rotation: 180 }) https://gsap.com/docs/v3/GSAP/CorePlugins/CSS Also there is no such ease as 'linear' - if you want linear interpolation, ease: 'none' is what your looking for. If I am not mistaken, any invalid ease like that would fall back to the default ease of 'power1.out'. Edit: It looks like 'linear' seems to be accepted though, and will result in no easing 🤔 And apparently that is the case since like forever in GSAP3 ...didn't even know that 😅 https://gsap.com/docs/v3/Eases/

While I definitely agree that a lot of times that might be true - probably even most of the time - I certainly wouldn't agree with 100%. There definitely are usecases where an onReverse can be handy in cases outside of events. That's why there also is a work-flow example in the helper-functions section of the docs that explains how to create your own custom onReverse() callback functionality, @MarcoCuel. https://gsap.com/docs/v3/HelperFunctions/ https://gsap.com/docs/v3/HelperFunctions/helpers/trackDirection/ It comes with caveats though - e.g. logically it will take one tick to update the direction as is explained in the orange 'caution' box over there - thus you might have to accomodate your own logic to that fact if you want to trigger things onReverse appropriately then. Some of the reasons that it is not included in GSAP's core are, that having it external like that keeps the core lightweight and doesn't require extra processing on the vast majority of animations that don't need this functionality. That last part comes directly from Jack (@GreenSock). If you have more questions, I'm sure he'll be able to answer them.

That's probably mostly a concern of your CSS styling and nothing GSAP related. Your cursor is set to position: absolute - that will be in relation to the body in your case. The page keeps on scrolling vertically, even if you fake a horizontal scrolling movement. Thus you cursor will also move up as it keeps scrolling with the body. The easiest way would probably be to just set it to position: fixed isntead.

As the GSAP Helper already mentioned, without a minimal demo it is close to impossible to tell for sure, but my best guess would be that you are using some CSS fraework like probably tailwind, judging from the classes on the element you are animating with GSAP. If that is the case, here's what tailwind'stransitionclass will add via CSS https://tailwindcss.com/docs/transition-property transition-property: color, background-color, border-color, text-decoration-color, fill, stroke, opacity, box-shadow, transform, filter, backdrop-filter; transition-timing-function: cubic-bezier(0.4, 0, 0.2, 1); transition-duration: 150ms; So my guess is that you have CSS transitions fighting with updates on the element done by GSAP. On properties of elements that you are going to tween on with GSAP, you should never have transitions applied. This older demo of mine illustrates why. https://codepen.io/akapowl/pen/JjmrMNy

Hello there. Here are the problems in your pen that are responsible for it not working: You are gettting an error in console - there is no such thing as SmoothScrollbar.init() - it is Scrollbar.init() instead; nothing related to GSAP. Also, as far as i know, smooth-scrollbar does not have an 'effects' property; so that is probably redundant, too. I would suggest removing that to prevent any possible problems that might arise from that. You don't have a layout/setup that would work with smooth-scrollbar to begin with; you'll need to apply proper CSS styling on the body and the container you're going to initialize smooth-scrollbar on for it to work; nothing GSAP related. In CSS as well as in JS you are targetting elements with the class '.item' but you don't have any such elements in your HTML, you only have '.item-1', '.item-2' and '.item-3'; nothing GSAP related. Your .item element has a height of 0 set via CSS. Although in a comment you say you're going to set its height via GSAP, you never do. Again, less of a GSAP specific problem. And finally: You are not declaring a specified scroller element in your ScrollTrigger, which you will have to do, as smooth-scrollbar does not run on the body element. This one is something GSAP / ST specific; For clarity, see the smooth-scrollbar example and documentation on https://gsap.com/docs/v3/Plugins/ScrollTrigger/static.scrollerProxy() Since a lot of your problems arise from not properly handling smooth-scrollbar in the first place, I would suggest having a thorough look at their documentation. Smooth-Scrollbar is not a GreenSock product, so you really shouldn't expect to get support for it in the GSAP forum. I implemented the raw basics to the fork of your pen below - and it works as it should. I give no guarantee that it is bullet proof with regard to smooth-scrollbar though; you should check on all that yourself. https://idiotwu.github.io/smooth-scrollbar/ https://github.com/idiotWu/smooth-scrollbar https://github.com/idiotWu/smooth-scrollbar/blob/develop/docs/api.md Hope this will help get you going in the right direction though. Good luck! https://codepen.io/akapowl/pen/KKERaYE

Hello there. To me this actually sounds a lot more like it might be an issue with your webpack configuration than anything related to GSAP. Which also makes me wonder, why you provide an example using vite, when you are actually using webpack in production 🤔 Below is an example that shows it working across multiple files. I just had to make sure to properly set the entry in the webpack configuration to an array of the pages I wanted to be bundled instead of just the default single file reference - because else webpack of course won't even know other js files you want to include do exist. Also since I wanted to access something stored in a variable in one file from another file, I needed to export it from that one file I created that varaible in, and import it in that other file I wanted it to be accessed in. That is just a small console.log of the smoother variable in header.js - but ScrollSmoother itself will still work without importing it there. Maybe that can help get you started finding the problem in your configuration. https://stackblitz.com/edit/webpack-webpack-js-org-fzollb?file=src%2Fmain.js

While you certainly can add those calculations to the start for each of your ScrollTriggers within that pinned element as shown above by Mitchel, actually you do not have to do that. ScrollTrigger does have a built in property to do exactly that for you in cases as such: pinnedContainer https://gsap.com/docs/v3/Plugins/ScrollTrigger/ So the demos below with that property on the ScrollTriggers set to the pinned wrapping element should technically behave exactly the same as those with the calculations for the start shown above. As I see he's been sharing that one demo a couple of times before, I'll also ping @Rodrigo just to make him aware. Of course there's absolutely nothing wrong with calculating things like that, it's just a different way to achieve the same result - but why do it when you can also let ScrollTrigger handle itself [Edit: except for maybe edge cases where you'd have to add some calculations anyway]. 🙃 https://codepen.io/akapowl/pen/mdoxqNL https://codepen.io/akapowl/pen/MWxVrgw

If you want to know how to possibly approach something like that, I would suggest having a look at this tutorial on Codrops. https://tympanus.net/codrops/2019/02/20/how-to-create-a-fake-3d-image-effect-with-webgl/ But it looks like they are not using GSAP whatsoever. Anyways, integrating GSAP into that will likely be the smallest part of work you'll have to do and probably the least complex. For the latter, I suggest having a look at https://gsap.com/docs/v3/Plugins/Observer/ But quite frankly, I also wouldn't count on much support here with achieving that yourself, as this will likely become quite the complex task overall, mostly related to logic related on how to handle three.js, and this free support forum just can't handle creating tutorials for any given effect you can find.

I don't think that is a ScrollTrigger problem to be honest - but more an issue about how display: contents works in the browser. If you set the start of your ScrollTrigger to something like '100px top' instead of 'top top' (because in your case it already has hit that spot thus the onEnter will not fire when starting to scroll) and inspect it in your browser's dev-tools, you can see the properties on it inline being changed as they should. So ScrollTrigger does exactly what it is supposed to do. But: Source: https://medium.com/@zylberberg.jonathan/what-is-css-display-contents-property-and-how-it-can-solve-some-interesting-problems-4fdff7363777 Since that is the case, i.e. it not generating any boxes, you won't be able to set most properties on it; neither via CSS nor via JS. Here is an example without any GSAP - neither the CSS opacity: 0, nor setting it via JS will do anything. So I'm afraid you will have to re-think your approach on the styling of your layout a bit. https://codepen.io/akapowl/pen/QWoqZxP

😅 Yeah, I already realized that myself (see Edit in post above). Thanks a bunch for the quick reply and the demo - much appreciated! It's been some time since I last touched on React, and it appears I tend to forget about its patterns; so this will definitely come in handy as a reminder.

Excuse me for hijacking. I was giving it a go myself earlier - but since I'm far from being an expert with regard to React, I wasn't sure whether to post or not. Here's what I came up with: https://codesandbox.io/p/devbox/usegsap-fork-9vd2cg?file=%2Fapp%2Fpage.tsx So just a quick question @Rodrigo. If you wanted the timeline to play/reverse specifically dependent on a state in React (because you might want to use that exact state to update something else on the page) would the approach I used be eligible, or do you see any problems using it like that off the top off your head? From what I understand, logic wise it should be pretty much like what you have suggested above - just taking a small detour via the state in React instead of triggering depending on the timeline's .reversed() 'state' directly, right? Edit: I just realized; Instead of the toggleTimeline function I could also just use a useEffect hook with the state as its dependency to toggle the timeline depending on the state - and in the onClick handler just set the state instead. That's probably more React-y; but I guess the question of the eligibility does still stand. https://codesandbox.io/p/devbox/usegsap-fork-forked-98wjvx?file=%2Fapp%2Fpage.tsx

Welcome to the GSAP forum. Here's what I found on a super quick google search: https://developers.squarespace.com/custom-javascript https://support.squarespace.com/hc/en-us/articles/205815928-Adding-custom-code-to-your-site Your question is very likely more related to how Squarespace handles things, than it is about GSAP. If you have any questions regarding GSAP directtly, we'll be happy to help on those. The ressources provided above should help get you started, though. Good luck with the project!