Leaderboard

It's hard to say without seeing it. Please make a simplified demo showing the problem.

Don't set transform and transform-origin in your CSS for SVG. It will not work in every browser, especially transform-origin. By default, GSAP uses the transform attribute for SVG elements. CSS > attributes. GSAP is correctly setting the transform, but your CSS is overriding it.

If anyone is wondering why setting the transform origin in CSS for SVG elements is a bad idea - besides not being consistent in every browser, there's a new property that you may need to use in order to specify where the origin relates to. Spoiler alert: IE/Edge doesn't support it. https://developer.mozilla.org/en-US/docs/Web/CSS/transform-box view-box is kind of like setting svgOrigin with GSAP.

I wasn't thinking about an eye when I posted my response. Resizing the movement vector if it exceeds a certain radius is one way you could correctly handle diagonal cases.

Welcome to the forums, @Mmagic. I noticed a few problems... In your "restart()" function, you were looping through all the child animations and calling "restart()" on each instance, which basically rewinds them immediately, putting them back at their starting state. When you're using "from()" tweens, that means they'll all be at their "from" values at that point. And then you're creating all the from() tweens again...from those same values! In other words, x is 500 and you're tweening x to 500 (no change). That's why it looks like nothing is happening. It's just a logic flaw in your code. That's the most common mistake when people use "from()" tweens - they often forget that it uses whatever the current values are as the destination values which can cause logic problems (not a bug in GSAP). Imagine clicking a button really fast - if the user clicks when the current tween is partially finished, the current (destination) values are now different than the originals. It can get messy. Of course you can use fromTo() if you need to specify both starting and ending values. It's totally fine to use from() - it's just important to keep in mind how they work. Also, if you're trying to clear out a timeline... //BAD / WASTEFUL: TL.getChildren().forEach(tw => { tw.restart() tw.kill() }); //GOOD: TL.clear(); Also, you do NOT need to reuse timeline instances. It's not wrong/bad, but I often find that it's easier/faster to just create a new instance each time in cases like this. It probably takes more resources to scrub all the old stuff out rather than just creating a new one. Remember, GSAP is highly optimized for speed and it releases things for garbage collection on its own. Lastly, you could consolidate this code: //LONG: const tween = TweenMax.from(".wrapper", 10, { x: 500, ease: Power0.easeNone }); TL.add(tween, 0.5); //SHORT: TL.from(".wrapper", 10, { x: 500, ease: Power0.easeNone }, 0.5); Happy tweening!

@OSUblake Thanks a billion times! I actually knew that - no idea, why I did it nevertheless... stupid me! (Pen is updated with comments.)

You need to set duration so class toggles back when you scroll further.

Ya there is a lot of code that I am not even sure what is the purpose of that. You are using container's height and width to calculate progress of tweens based on where the cursor is inside the container. Now your container can be a div or window and you need to know how using either affects the implementation. First thing you need is to position your elements where you want them when mouse is at center and from that position eye will translate. You can't use pageX in your actual project because if you scroll it will throw off your calculations. You need to calculate mouse position like I did if your page scrolls. You also need to reset value of rect on resize and scroll event. Figuring out how much the eye should move doesn't need all that calculation, you can just use a number based on radius of your circles.

@OSUblake is right on, of course. And if you simply want to remap a wider/narrower x/y range to another, here's an example of using a tween's progress accordingly: That's not really what I'd use for an eye-following thing because it's not actually measuring things with true angles from the center of a circle (so it goes off the edges at the diagonals), but I was trying to keep things as simple as possible to demonstrate the concept. You basically create a tween for the x-axis and another for the y-axis and that goes from left to right (or top to bottom) and then simply remap the ratios, like if you're basing it on the mouse position across the whole screen width/height (or whatever). Of course you could tween the progress of another tween too if you want things to animate/ease to the new position. If you need help with that, let me know. Happy tweening!

It looks like the Chrome (in responsive mode) is automatically firing a "pointercancel" event even though Draggable does everything in its power to avoid that. It's basically ignoring the preventDefault() call, and acting like you want to touch-scroll the content. Definitely seems like a browser bug to me. The only way I could find to resolve your demo is to simply add the following rule to the CSS: .item { touch-action: none; } Again, I'm pretty confident this isn't a Draggable bug. But at least there appears to be a relatively easy fix you can apply to your CSS. Does that help?