thei

That works nicely. The "inconsistency" I was seeing was due to the inertia plugin and not having an onThrowUpdate. Now that it's updating on drag and throw it seems to work well. Thanks!

That seems to work on slow dragging, but not on fast dragging or on inertial-throwing (or possibly my fast dragging is getting confused with inertial-throwing, it's difficult to tell) I'm assuming onDrag throttles itself in some manner when it's getting a lot of events quickly? This gives it a very inconsistent and faulty sort of feel when it sometimes goes click and sometimes doesn't (it's much worse in my actual implementation, which has wider slides that slide a lot further, which seems to tend to use intertial throwing more heavily)

I don't understand how knowing what direction my carousel is dragged helps me know when a circle within the carousel (a slide, essentially) is overlapping the target circle. I don't want to know when it's finished dragging - I want to know as each circle is dragged. For example, if someone were to drag the carousel from 1 through 8, stopping on 8, it should make 7 clicks, as each circle crosses the target circle. Effectively simulating the common haptic feedback effect you see on things like this.

I have a basic slider using Draggable. I want to be able to do something (play a sound) when each item in the slider crosses its snap-point. That is, as I drag it, when each slider circle is centred in the middle black circle, the slider should go "click" - so dragging it from one end to the other would go "click click click click" etc., one click each time a coloured circle is centred inside the black circle. I know how to play sounds etc, the question is - how do I reliably and efficiently detect when the coloured circle is inside the black circle (that is, when the draggable is at a snap-point)?

Thanks Not sure why I didn't try that... I even knew about it for background colour and stuff but for some reason assumed transforms would be automatically included and never even tried it. The absolute: true ones are still broken, but I guess I don't really care why that is as the others are working so I shall just use that.

See the before and after rectangles. FLIP should animate between these two states, but it is ignoring/overwriting the rotate and scale values. Also if I specify "absolute: true", as per the last two rectangles, it goes horribly wrong. Why? How to fix?

Actually, it is wrong in my opinion, though it's perhaps arguable how it should work? However it's consistently wrong by +100vh (I assume from my absolutely positioned 100vh element prior to my first pin?) so I'm just subtracting innerHeight and it all works. See these two. Note how the yellow box is offset due to the scroll distance factoring in the pin. I'm not sure if this makes sense or not, but it's confusing and if it is the correct behaviour, then I'd ask the question - how would one calculate the actual scroll offset in real pixels, if the reported scroll offset itself is different? https://codepen.io/nedmartin/pen/dyeeLNV https://codepen.io/nedmartin/pen/ZEooZYE

My bad - ignore that. I still had offsets in from previous attempts to correct it when it was wrong. Now that I've removed those, it seems to be working as expected.

It would appear that ScrollSmoother.scrollTop() is returning incorrect values

I believe you're right, I probably had a cached file - it was actually difficult to update, had to clear yarn's cache and delete node_modules, or it just kept reinstalling the same one. Now that it is actually using your new beta, it appears to work properly ? - I can scroll all the way to the bottom! I haven't done any testing on mobile or whatever, but it works on my most complex page in both Edge and Firefox, where it didn't before, so I'm guessing it's good. I'll do some proper testing tomorrow. I've updated the demo page in case you still wanted to look through your debugging logging, but given that it seems to be working, I'm assuming you don't need to. Thanks for spending the time on this. I'm impressed in the turnaround time for what I assume was a complex issue/not actually supported feature. In future I'll try not to assume things I've done many times before will work and leave testing major functionality until the last moment and then it'll be a whole lot less stressful ?

Thanks for all your effort, but sadly no noticeable difference - still can't scroll to the end if I have nested pins. I've updated https://reliable-heliotrope-700433.netlify.app/demo/ in case that's of use, though it looks basically the same. Note that it has a 5 second delay before it runs GSAP (debugging I forgot about and left in when I deployed it, to ensure Vue had fully finished and everything had loaded etc)

Unfortunately after a lot of effort I've been unable to make a codepen that illustrates the problem. The best I can do is: Here is a codepen that unfortunately seems to work just fine, and here is the actual code deployed to netlify, where it does not work. The netlify code is built using Nuxt so I'm guessing that's the cause for the problem, however I've tried to normalise them as much as possible - even adding the extra pointless wrapper divs that exist in the Nuxt generated code to the codepen code. I've also tried running the animation code after a 5 second delay and things like that, to rule out any Vue virtual dom delay weirdness - it all makes no difference. If I get rid of the nested pinning, 100% everything works perfectly as per how GSAP has always worked, with no bugs, all great. But as soon as I have that nested pinning... problems. But annoyingly... the code in the codepen works. Interestingly, resizing the page causes it to work - or at least, sort of work. However, manually calling Scrolltrigger.refresh() does *not* cause it to work, *unless* it's already scrolled as far as it can, in which case calling Scrolltrigger.refresh() *twice* causes it to allow it to scroll further (but usually too far) note that I've got the code window.st = ScrollTrigger; in there, so you can call st.refresh() to demonstrate the above. https://reliable-heliotrope-700433.netlify.app/demo/ https://codepen.io/nedmartin/pen/eYrreBX

I have updated to this version and the pins (at least the ones I can scroll to) do seem to all work correctly, however, I can't scroll all the way to the bottom of the page. I'll see if I can make a codepen but it's getting complex.

Thanks for looking into this for me. The latest version I can download seems to be 3.11.2, which is what I'm already using. I see that the codepen assets is 3.11.3f. Is there a way I can download the beta you mentioned in my actual project (I'm using the yarn add /.gsap-bonus.tgz method of install, it's a Nuxt-based site that's already had a bit of time spent on changing gsap stuff to allow cross-page animations without ScrollSmoother breaking things, so I'd rather not have to mess with the build system at this stage to change how scripts are loaded if I can help it?) It is significantly more complex than the sandbox example (I have numerous pinned elements that also run simultaneous scrubbed scrolltrigger animations for example) - if it works that'd be great and I feel like nested pinning would be a useful feature for you to have. If not, I unfortunately don't have the time to mess around testing much anymore - project was due last week and I'm well over dev budget and working for free now.

Thanks for this. Unfortunately, I don't think this will work in this instance. Why? A few reasons: The pinned part itself contains pinned parts - something I now know that GSAP can't do (they should really update the documentation to make this clearer - the way it mentions using pinnedContainermakes it sound like it does support this, so I wasted a huge amount of time trying to get it to work and blaming Vue.js dom manipulation and all kinds of complicated things rather than questioning whether it was something GSAP could actually do - random trivia: I got 99% of it to work by refreshing the next animation upon completion of the previous one - basically, once the previous pin has completed, rerunning all the calculations for the next one seems to make it work, but it was becoming an fragile house of cards and was not reliable) The pinned part is not full viewport height - content from other parts overlaps it, so even if I remove the pinned child parts from the pinned parent and get the client to accept that simply can't be done, I still can't do any full-height workarounds like you've done. Unfortunately, some of the content that overlaps the pinned part is itself a complex pinned animation, so I'd have to get the client to accept that none of the stuff at the top of the site can be pinned, which is unfortunately where a lot of the "cool stuff" is supposed to happen. What you've done is currently my emergency fallback though - but it requires that I modify the design such that the first part has no pinning in it and is always a minimum of 100vh high with no subsequent parts overlapping it, which breaks the client's design and I'm pretty sure the client is going to say that aspect of the design is important, being basically the first thing any visitor to the site sees. But I'm way over time and over budget so at some point a working site that doesn't do what it was supposed to is better than no site at all I suppose ? I've already wasted lots of time trying things like the above, but I'll try using a timeline to manually animate the fixed content to move negatively inline with the scroll and/or manually create pin spacers to see if that is smooth enough to work, but I'm guessing it'll break the subsequent pinning in the same way that using pinning does as it's effectively what pinning does. Unfortunately ScrollSmoother makes it impossible to actually fix the position of anything without using pinning (or manually doing something similar) My only other idea is to get rid of ScrollSmoother, and then that opens up a whole pile precisely-timed toggles of position:fixed vs position:static changes and CSS solutions, but getting rid of ScrollSmoother makes all the animations across the rest of the site noticeably jerky, so I'll then need to play around with them, see if I can find smoother-looking easings. Something that seemed simple (and which I quoted a simple amount of time to do) has turned into a nightmare. If anyone does come up with a magical solution that I haven't thought about I'd love to hear it so please do keep the ideas coming. In the meantime I need to go back to the designer and ask that they change the design to something that can work, but unfortunately this is the very top of each page on the site so it's a fundamental aspect of how the site has been envisioned, and so far they have been incredulous that something as common as a slide-up reveal on top of fixed content, which itself also contains animations, which they have seen all over the internet, is impossible for me to do, and have asked that I look into alternative animation frameworks - and I tend to agree with them, this doesn't seem like it should be complex and it seems like it's something that would be commonly done?

Ok that's a fairly serious issue then, if it's simply not supported ? - probably explains why everything is broken, even the seemingly simple stuff, when I've had very few problems in the past and GSAP has traditionally been really good and solved the silly issues for me so I don't need to worry about them. I know about the differences between pinning via transforms or fixed - I'm using ScrollSmoother (ideally, some of my scrubbed animations look a bit rubbish without it) so can't use fixed - I mention it here only because it seemed to have different bugs depending which method was used (though I guess if it's not supported, they're not bugs) The above codepens illustrate the simple effect I need - I don't think I can really make it much simpler. The first section of the site (the green "Top 100vh section" in my codepens) needs to slide up, revealing the rest of the site fixed ("pinned") underneath. This "rest of the site" area will then contain multiple animations, many of which contain pinned areas of their own (the usual stuff you'd expect on a site - ranging from simple pinned headings through to complex slide reveals, etc) Because of ScrollSmoother I can't use any form of actual "position:fixed" to achieve this, hence pinning it with ScrollTrigger. However, you've now just told me that means I can't pin anything else inside this pinned section (which is effectively the "rest of the page", so is going to contain all kinds of animated and pinned things) Any ideas? Or do I go back to the client and tell them what they want is not achievable and get them to come up with some alternative design that doesn't involve the first section sliding up over a pinned rest-of-the-site? And yes I am using a paid version (and have been using GSAP for years), but I don't want to post from my work account.

I built a site using ScrollSmoother, only to find out that ScrollSmoother doesn't really work as soon as anything complex is required. I have now run out of time to troubleshoot this any further as the site is already overdue, so I am trying to remove ScrollSmoother and revert back to a ScrollTrigger-only implementation. Unfortunately, removing ScrollSmoother causes other weird problems, and it's doing my head in. I've used GSAP for years and never really had any issues. Am I losing my mind, or is something stupid going on here? Note: This is a copy of the below with ScrollSmoother and its wrapper elements removed. Apologies for the inconsistent JavaScript, I started writing the codepen specifically and then just copied bits in from the site I'm working on with the quickest modifications to make it work in the codepen and haven't bothered making it neat, so it's all over the place. *Edit: Apparently all Codepens just go to the bottom of the post no matter where I put their links* Here is an example (copied from the above) without pinType: 'transform'and another example (also copied from the above) using pinType: 'transform' pins, along with the original ScrollSmoother example (which can't scroll to the bottom): https://codepen.io/nedmartin/pen/KKRQYLq https://codepen.io/nedmartin/pen/MWGVvga https://codepen.io/nedmartin/pen/zYjWdvZ

Update: I added another pin to my codepen, which also does not work. Why does the pinned text scroll down twice as fast, instead of remaining pinned? I've been using GSAP for years, way before all the fancy v3 stuff, and never had all these problems with even the most basic bits like trying to pin some text... I don't know what's going on! ? https://codepen.io/nedmartin/pen/KKRQYLq

It's interesting that that seems to works in the simplified examples, but sadly it doesn't work for me on my more complex actual site (which contains several pins and many animations, etc) ? I tried setting all pin-spacers to box-sizing: content-box|border-box|unset !important, and that also did not work (and broke some of the pinned items quite a bit). Unfortunately I don't have the time or knowledge to dig through and try to work out if some pin-spacers need to have box-sizing changed and others don't, and I don't have the time to create a more complex sandbox with more pinned elements in it that more closely replicates my actual site just so others can debug their code. If it's something complex to do with something peculiar I'm doing with my site then fair enough (it has lots of grid- and flex-based layouts and is fairly complicated), but it seems to me that even the very basic use of ScrollSmoother and pinning is broken so it's not just me? ?

I believe that's just some kind of coincidence - my basic example happens to be broken by 100vh for whatever reason, so adding the spacer looks like it's made it work. Unfortunately it doesn't fix the issue on my site. In the actual site I'm building, the amount "broken" (i.e. the amount it can't scroll) doesn't seem to be any multiple of 100vh's (I tried adding a 100vh, 300vh and 400vh spacer just quickly to see it it works - 300vh isn't quite enough, 400vh is too much...) I suspect it's probably the total amount of pinned space amongst all pinned elements if I had to hazard a guess - but as far as I can tell, ScrollSmoother is very broken. I'm not aware of any way I can calculate the total amount of pinned space in order to add it to a spacer element - but surely that's a task that GSAP should be doing for me anyway? I'm really hoping someone can come up with a simple solution for this or point out the silly thing I've done wrong, as the project I used this in is already overdue and I made the unfortunate mistake of assuming ScrollSmoother was production-ready and the work required to remove it is proving to be a lot more than I thought - removing ScrollSmoother does fix this problem, but it makes the animations very jerky and largely ruins the "smooth premium" feel that was important for this project.

When using ScrollSmoother, I am unable to scroll to the bottom of the page if I pin something inside something else that was also pinned. ScrollSmoother appears to think that the page has "finished" earlier than it really has. Calling ScrollTrigger.refresh() does *not* fix the problem. Also, why does my nested pinned content not pin, and instead scrolls down twice as fast? See https://codepen.io/nedmartin/pen/KKRQYLq for a basic demo.

I'm using 3.11.1 - I'll update to 3.11.2 I suppose. It does seem that ScrollSmoother is perhaps a bit too immature for use in a production site, but unfortunately I did not know that prior to using it, and had used it a few times before and found that it made things I used to manually do using a combination of ScrollTrigger and native JS much simpler, so I didn't really stop to test it first and just assumed it'd work with the same level of reliability that the rest of GSAP has exhibited. Since now having to test it, I've found that it's got all kinds of issues with mobile and third-party DOM manipulation and what not. Unfortunately switching it out now would be problematic, as the rest of GSAP animations are all interlinked with it. Context looks very interesting/useful here, I did not know about it and will look into it further. I'm aware that I need to handle refreshing GSAP on DOM changes, it's just that the major point of using GSAP (for me at least) is that it handles most of this tedious stuff automatically behind the scenes. As soon as it doesn't, I may as well write stuff myself - the basic concepts minus all the tedious workarounds are usually pretty simple. I had assumed/hoped that ScrollSmoother would have some magic way of handling all this (which it sounds like it may be working towards with context and it's just a bit too new still?) Unfortunately I don't have time to create a mockup project in a sandbox and I can't put my actual project into a sandbox as it's a commercial client project (and also large and complex), but any Nuxt-based two-or-more-paged site with smooth scrolling should exhibit these same problems. When I Googled for solutions earlier I found several people having similar problems who had made sandboxes.

Have you actually looked at that example? It's probably simpler to actually write a scroll-smoothing function from scratch, than it is to use that "workaround" ?. It's also seems to me to be an overly complex way of achieving what can be done by simply doing this, or am I misunderstanding something? mounted() { this.$nextTick(function() { // do animations }) }, beforeDestroy() { // kill animations }, One of the main reasons (in my opinion, the only good reason) to use a framework like Vue.js, is to take advantage of its virtual-dom manipulation, which works from basic components right down to the "page" level. This allows for seamless animations and transitions between things which aren't possible using a traditional DOM. However, if you have to kill your animation framework and recreate it between each virtual-dom to real-dom manipulation, then you've just lost the main reason you'd use a framework like Vue.js in the first place? Either way, the "workaround" above is very far from "simple". So I'll repeat/rephrase my original question: Is there a reliable, workable and simple way to use ScrollSmoother in a Nuxt2-based project (ideally without utilising workarounds, like that quoted above, that defeat the purpose of using Vue.js in the first place, but either way... simple is the keyword here)? Note that this is different to individual component animations, which obviously can't be run until the components that need to be animated actually exist - but the page scrolling exists across route changes, and needs to work as such to be usable for route-change-based transitions and what not (which as I've said above, seems to me to be the main reason one would use a framework like Vue.js in the first place, at least from an animation perspective) Anyway, thanks for the example, until (or if) ScrollSmoother works with Vue.js, I can use that to hack around it, but I was hoping for something simple that'd just work - that's what I like most about GSAP, most of it is stuff that can be done relatively easily without GSAP, but using GSAP makes it trivially easy. This seems like an exception to that.

I've used ScrollSmoother in a few previous projects and liked it. Unfortunately I've just built a Nuxt 2 (Vue.js 2) site using ScrollSmoother without looking into it enough, and now I've found that ScrollSmoother is not compatible with frameworks that use shadow-DOMs and dynamically manipulate the DOM (such as Vue/react/etc) to animate page routing, rather than using the more traditional "load a new page" approach. It seems that when the framework updates the DOM, ScrollSmoother doesn't know, and it all goes horribly wrong from there. I've seen some posts here about absurdly complex hacks that supposedly make it work (for example, see below) but so far the "solutions" I've seen are unworkable and ridiculous - so my question is: is there a reliable, workable way to use ScrollSmoother in a Nuxt2-based project? Or have I screwed up and I'll need to rework all my GSAP-based code to use some alternative? Thanks

And how would one do this?