MSCAU

Very good, thanks!

I am using Draggable for the first time. I find that once an item is Draggable, I can no longer right-click to inspect it. This makes it difficult to debug, especially when there are many nested elements. Is this the intended behaviour? Is there a way to work around it?

Thanks, both! Works very nicely.

I have foreground and background elements animating together for 2 seconds. To keep the code simple I am only using GSAP to animate the (more complex) background elements while using CSS transitions for the foreground elements. Does anyone know which GSAP ease best matches the default CSS transition function of "transition-timing-function: ease"? I note that this page mentions that it is equivalent cubic-bezier(0.25,0.1,0.25,1), whatever that means: https://www.w3schools.com/cssref/css3_pr_transition-timing-function.asp I see that it's not quite in sync with GSAP's "power1.out".

Following another post by @OSUblake in these forums using the most basic Vue setup, I can see that an array in Vue can be tweened with GSAP, but it's pretty useless unless the DOM is updated too with Vue. Is something in Greensock preventing my CodePen {{ arr }} from updating during the tween? See also:

How should we phrase this with GSAP v.3? It's not clear from the docs and all forum posts on this predate v.3.

I have not been able to reproduce this in a simple example (or at least my simple example doesn't exhibit the same issue) so I'm just looking for someone who might be familiar with how roundProps works under the hood, or who might know enough about Vue + GSAP to provide a hint. I have a Vue instance which displays a list of user comments. Each comment is defined as a component in Vue. Comments can either be "live" or "pending". As each pending comment is mounted(), I start a countdown, giving the user 60 seconds to edit their comments before the status is changed to "live". I use Greensock for the countdown, and display it inside the comment template. Certain user actions cause the countdown to reset. Here's the thing, when I use roundProps (to keep the numbers tidy and simplify the template), resetting the countdown on one comment causes all other countdowns on the other pending comments to reset. When I comment out the roundProps line, I have no such problem - it works as you'd expect. Here is the relevant (Vue method) code: countDown() { var _this = this; _this.tween = TweenMax.to(_this, _this.seconds_left, { age_now: 60, // roundProps: ["age_now"], ease: Linear.easeNone, onComplete: function() { _this.comment.status = "live"; } }); }, It doesn't make any sense to me that the roundProps property by itself would create such havoc. It seems to be "dirtying" the counters in the other comments.

Yes thanks. I find I can run both of these successfully: tl.to(".div1", SPEED, {borderRadius: "+=10%"}); and tl.to(".div1", SPEED, {borderRadius: "+=10% +=10%"});

It appears that a simple borderRadius tween with a relative increment value only affects the Y component of the CSS border-radius property (#1 in CodePen). I can get around it using an absolute value (#2 in the CodePen), but I thought this was odd so should be reported. Thoughts?

Thanks to the above discussion, I now have a countdown clock which doesn't pause when switching to a new tab: https://codepen.io/MSCAU/pen/XyXoba

Aha, the light bulb has gone off! I had no idea tweens are crystallized at the time of instantiation. Thanks for explaining that, @Dipscom. I like @Greensock's suggestion too which led me to the apposite video on https://greensock.com/docs/TweenMax/invalidate and the solution to the problem: https://codepen.io/MSCAU/pen/oPxEwY

Thanks, @Dipscom, that doesn't sound right. The function $('.floater').click(function(e) {...} runs before every animation and already sets the fixed_offset_top value. Having that value change triggered by a window resize event rather than a click doesn't sound likely to make any difference. And as you can see here, it doesn't: Maybe I'm not understanding what you mean by "recreate your timelines".

I have a toolbar which can be either at the top or the bottom of the window (position: fixed). I use tlup and tldown tweens to transition between the two positions. I want this to continue working smoothly when the user resizes the browser (eg. by rotating their mobile device - hence the fixTop and fixBottom callbacks). Despite the fact I'm recalculating the pixel distance between the top and bottom of the screen before each pass (via the fixed_offset_top variable), once the window is rotated, it seems as though my animation is preserving some 'memory' of its previous tween target as it doesn't end up in the right place. I've read this topic and applied clearProps:"transform" to some effect, but it's obviously not a complete solution to my problem:

Thanks, Sahil! You've been a great help.

Hmm. I think it's because at the time I'm setting up the callback for tl4, tl5 hasn't been declared yet and the tl4 callback expects tl5 as a parameter. I'm happy to take suggestions on how best to structure this!