GreenSock

Another option: just use a super small data-speed: https://codepen.io/GreenSock/pen/rNbqwMQ?editors=1010

@Chromium One of the MOST important things to us at GreenSock is cultivating a warm, smart, non-shaming community. We're widely known as having forums that are uncommonly so. Most tech communities are characterized by harsh, arrogant, shaming responses. When someone has a question, it takes a lot of humility and courage to risk posting. We get it. We really try to be compassionate and gentle. It sounds like you felt criticized and insulted. I'm very sorry if that was your experience. We actively work to avoid that; if we failed, I hope you'll forgive us. Glad we ultimately got on the same page with a solution. 🥳

Yes, @Rodrigo is correct about that not being a built-in feature but you could probably get that functionality with enough custom code. For example, set up a listener for the "scrollEnd" event, and then create a gsap.to(...{ scrollTo }) tween that's however long you want, and apply your snapping logic inside the handler to calculate the scroll position. Just an idea. Good luck!

I sent you a private message with details. ✅

Ah, maybe there's the disconnect - we cannot approach development that way with our tools. We work very hard to build trust with users so that things "just work" and GSAP is consistent. So if we tell users that they can use motionPath in a Flip.from()...but it'll only work in 5% of the cases and in all others it just totally breaks, that's no good. We have to think through all the edge cases and ensure there is consistency across the board as much as possible. Imagine if you used Photoshop but it only worked on images that have mostly red pixels and no human faces? Or you bought a car that only functioned on 4% of the roads in your city. 🙂

Unfortunately it doesn't at all 🙂 I think you might be missing a fundamental logic impossibility here. Well most paths have x and y. In my example, I said a squiggly vertical line, thus there is some "x" movement in a squiggle. But in this case you're saying that the Flip.from() would totally ignore the motionPath? That's one of the key problems - the start and end points can't just magically be the same based on any motionPath you feed in. What if the start/end points are at a 45 degree angle from each other, 100px apart...but the motionPath you feed in has the start/end points at a 174degree angle from each other and 800px apart? How could this possibly be expected to work? Let me use an extreme case to make the point - imagine your <path> is a circle. So the start and end anchor points are in exactly the same place, and you use that as the motionPath on a Flip.from(). What would you expect to happen? Are you starting to see the fundamental logic problem in this suggestion? Or am I missing something?

I still feel like we may not be connecting here... Can you please try answering this?: The magic of Flip is that even after you totally change the DOM and maybe reparent an element, it applies x/y/width/height offsets to make it look like it's in the original position. So let's say you Flip.getState(el) and then reparent it so that it ends up being exactly 100px to the right of where it was originally, and Flip figures out that it must animate x from -100 to 0. Great. But now let's say you add a motionPath:[...] to that Flip.from(), and the path data is from a 500px completely vertical line. How are you expecting this to work? You said that motionPath should take precedence. So let's say el.x starts at 0. Then you reparent your element such that it's now 100px to the right and Flip.from() would normally apply x: -100 to map it to that original position...but there's a motionPath that's a 500px totally vertical line. If that takes precedence, that means the element just suddenly jumps up 500px directly above or something? Can you see how it will no longer look like a proper Flip animation because it's not being mapped to the appropriate x/y position since the motionPath took over?

That effect should be applied with an attribute, not a CSS stylesheet. That's more compatible and DrawSVG knows to look for that too. https://codepen.io/GreenSock/pen/dyLqXvX?editors=0010 Is that better?

Maybe think of it like this... Let's say a you create a motionPath that (in an over-simplified way) animates from 100 -> 200 (a motion path is basically a bunch of coordinates, so let's say these are the coordinates). I'm only focusing on the "x" values for simplicity. Now let's also say you create a Flip tween that dynamically calculates the distance between two targets such that x goes from -152 to 0. It sounds like you're saying "just make motionPath work with Flip seamlessly" but how exactly would you expect that to happen in this scenario? You've got a motionPath that'd make x go from 100 to 200 over the course of the tween, and a Flip animation that makes x go from -152 to 0 over the course of the SAME tween. How can both happen simultaneously and seamlessly? Perhaps I'm misunderstanding you, but this seems like it's logically impossible to accommodate. You appear to be thinking of a motionPath more like an ease (style of movement; a matter of pacing/timing which could be applied to any interpolation) rather than an actual set of coordinates. For example, imagine a 500px vertical squiggly line that serves as the "motionPath"...and you want to somehow apply that to a Flip animation where a box goes horizontally 100px directly to the right. Help?

Yeah, a fundamental problem is that your target element is inside a position: fixed element, and the Flip.fit() does calculations based on the normal document flow. Flip.fit() would indeed work correctly BUT you're wiring that up to scroll position. The element you're fitting it to is affected by scrolling, but the target element isn't because it's position: fixed. So, for example, let's say that the element you're fitting it into is 500px directly below it - Flip.fit() would basically say "move 500px down and you'll be on top of that element." but you're wiring it to scroll which effectively MOVES the fit position. When you scroll 500px, the spot it's supposed to fit to is now 500px higher. If the target is position: fixed and it animates 500px down while scrolling, it would of course end up where that original fitting element was BEFORE scrolling. It probably is possible to figure out all the calculations, but this well beyond the scope of help we can provide in these free forums. If you need more help, you could post in the Jobs & Freelance forum or contact us for paid consulting services. I wish there was a super simple solution to offer.

Yeah, that's the nature of dynamically calculating velocity because you've always gotta choose how much "recording" to do time-wise and then compare the values. But I'm not sure why you're not just pre-calculating the velocity based on the linear tween's distance and duration: const velocity = ScrollTrigger.maxScroll(document.querySelector("#scroller")) / 10; // change / duration This demo shows a general idea of how the values are calculated, although in ScrollTrigger the measurements are always at least 50ms apart: https://codepen.io/GreenSock/pen/GRLXZXZ?editors=0010 In short, I think there's probably a much cleaner way to do what you're attempting without using getVelocity().

Just to be clear, when you use the tools in Webflow, you'd just use the normal JavaScript files (downloaded in the ZIP) - the token is only necessary for using the private NPM registry. Your license covers an unlimited number of your work products while it’s active, like Rodrigo said. The only caveat is that it covers your unedited work, meaning that if your clients/customers want to make any changes, they should get their own license. Otherwise, it’d make it easy for a huge company to circumvent the license by hiring a freelancer to start a project and then take it in-house and piggy-back on that single-developer license without getting their own license for their numerous developers. See what I mean? And please don't share the bonus plugins in cloneables which would make it easy for other developers to piggy-back on your membership. It's totally fine to use them in your custom projects for clients of course. 👍

It's very difficult to troubleshoot without a minimal demo, but my guess is that maybe your target element doesn't exist(?) If you still need some help, please make sure you post a minimal demo that clearly illustrates the issue (like a Stackblitz). Here's a starter template you can fork: https://stackblitz.com/edit/react-cxv92j

Hi @denglertarea23 I noticed two problems: You don't have a "Business" Club GSAP membership, but you're trying to install the members-only package via the private repository. You don't have access to that. You must sign up first. https://gsap.com/pricing You must not have configured the .npmrc file properly, because according to your error code, it's trying to find that package in the main npmjs.org registry instead of the private npm.greensock.com registry. Make sure you follow the installation instructions carefully. https://gsap.com/install

In case it wasn't already clear, that "jumping" that occurs when you don't have enough elements to "fill" the area horizontally is not a bug or anything - an element cannot exist in two places at once. Like you can't have half of the element showing on the left side of the screen while the other half of the element shows on the right side of the screen. It's in one place or the other.