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?