Friebel

A quick look tells me this is a 2d canvas-animation. Eventhough it looks and simulates 3D. I understand you probably mean the hickup in the beginning, but to optimize the full animation I would advise you to switch over to a 3D framework like Threejs which uses WebGL and therefore uses the GPU instead of the CPU. Some browsers have acceleration on 2D canvas, but with WebGL everything is way more optimized and you could even use 3D shaders which are way faster than javascript and run in parallel on a graphics card. My advise would be to dive into and learn threejs. You can use it together with gsap.

I think this explains why this issue occurred to a certain level. Great to know! That said, as I wrote in another thread just now where I had an error-message in the Firefox console about 'oldParent' being null; I have some new findings according the above: 1) When settings transformOrigin with gsap.set() to a DOM object (which is in fact a clone of a SVG Circle DOM element, which IS on the DOM), but not appending it to the DOM before gsap.set(), the transformOrigin needs different values than when it IS appended to the DOM first. In version 2 this wasn't the case, but in gsap 3 (probably because of the reason you wrote above), it is. 2) When using set() on a DOM element not being added to the DOM yet, when using gsap 3 there an error is raised by Firefox and the animation wouldn't load because it holds on that error. But other browsers seem to not having any issues with it and run. But the other browsers need to have a different value set for transformOrigin when not appended to the DOM though, as stated in point 1 above. So conclusion to me here: Gsap 2 somehow managed to set values with set() on a DOM element currently not connected to the DOM without problems. Even the transformOrigin values needed to be set the same as if the element was available in the DOM. But because of the inner workings of gsap 3 (origin-switching smooth?) we shouldn't use gsap set() and so on on DOM elements currently not available in the DOM as it is causing unexpected behaviour. With adding the element to the DOM first and using set() after that that also solved the last bit I had in my previous conclusion: In gsap 3 we still need to set the transformOrigin on the cloned element (so it's not being transfered over by cloning, as you also explained why), but we can now use the same transformOrigin values on the cloned element as on the original element (instead of needing to have a different value on the transformOrigin of a clone, as I needed to on the element not being on the DOM first).

I think so too I just did some testing and that was the case as you wrote; I set the transformOrigin with gsap.set() to a cloned svg element that was added to the DOM after gsap.set(). Now I reversed the order it's not throwing the error anymore in Firefox and shows the animation fine. Except for that there is a difference in setting the transformOrigin on an object ON the DOM vs an object NOT ON the DOM; I had to use different values for transformOrigin now it's put on the DOM first. Which also explains the issues I had in another thread (I will response there). Maybe that little difference in the method was just the make or brake ingredient in gsap 2, as with gsap 2 it didn't matter if the element was on the dom or not, as the transformOrigin was working anyway on a set() and FireFox didn't complain either. Guess the conclusion is that gsap 3 does things different than gsap 2 causing setting transformOrigin on an object not being on the DOM to fail in Firefox, and to have the wrong outcome with the same transformOrigin in other browsers. In other words; in gsap 2 we could set the transformOrigin to an element not (yet) on the DOM, where in gsap 3 that's not possible anymore. I didn't look into the _getBBoxHack() function, but at first sight it looks like a thing I once noticed ant that's that the original getBBox() js-function is not able to measure DOM elements currently not on the DOM or as I believe even when display is none or even visibility is hidden. I guess you have found a workaround for that with _getBBoxHack()? It would actually be great if you did! I saw callbackScope in the documentation and I like that. The thing I'm talking about here though is the fact that everywhere in ES6 classes 'this' stands for the class-object normally and if we use event functions we normally use arrow functions or bind(this) so this inside that event function is the class/object it is in. But when using gsap event-functions like onUpdate, onComplete etc. that behaviour is different. Well we could still bind(this) to these functions and treat them the same, but to me it's not sure how we could access that tween than or its targets, so so far I couldn't find a way to make that work. To me as a developer this feels counterintuitive in ES6/2015+. Well at least to have 'this' as per default set to the tween. Because there suddenly 'this' stands for the tween it's triggered by but I would rather bind(this) the function and have it set to the class/object it's in as I do everywhere else. As a developer, although I understand why you did it, I find this default confusing and error prone, because it's so different than the rest of the philosophy of ES6/2015+ classes in my opinion. With this we now have to send the real 'this' (so the class/object) as an onUpdateParam to use that inside the onUpdate() function. That works, but now we have the situation that everywhere in the project 'this' is the class/object itself, but suddenly in these event handler-functions 'this' suddenly is a tween. So I find myself adding all kind of warning-comments in my code there to indicate that 'this' is not what I would expect, but the tween instead, and that a 'self' functionparameter I created now is in fact the 'real' 'this'. To me that's the other way around. I'm not sure if we can change that default behaviour (I've believe I've seen it somewhere in the docs, but I might be wrong or forgot where and otherwise we could always use a bind(this) ourselves), but to me as a developer it would make more sense to have that behaviour turned off per default and have the tween-object inside a function parameter. Than we could bind(this) the event handler functions still, like we do everywhere else, and still reach the tween-object with a function parameter. So my question now is this: Am I missing something here and is what I'm after already possible the way gsap 3 is now somehow? Or would it otherwise be possible to add the tween as a parameter to the event-function instead of the other way around (like in gsap 2)? And if there is a config to reverse this behaviour, would it be possible to set that per default to have the tween inside the event function? What I mean with 'staggerTo() doesn't work' is that the staggerTo() method seems to be gone in version 3. At least I had different kind of issues with staggerTo() and when I looked in the v3 docs for staggerTo the search didn't return any results, so I figured 'staggerTo' is gone and needed to be replaced with a .to() with a 'stagger: { each: 0.2 }' inside to have the same behaviour. But than I bumped into other issues, like the 'this' as described as above. But also the 'target' I previously used inside event functions like onUpdate(). That seems to be replaced by targets(), but to me it's not clear on staggers how to use that as suddenly there are obviously more targets. So I tried targets()[0] and in some cases that solves the problem, but in other cases not. I'm doing something wrong there, so now the stagger is not staggering anymore, but directly jumps to the end result. That's obviously something I'm doing wrong, but I'm not sure what's the supposed right way of doing things here. But I need to dive in specifically on that point in an isolated project. The reason why I called this in my previous post is not that it's something wrong in gsap, but that it takes time to figure this kind of stuff out to know how it is supposed to work in version 3. That comes with my job, so it's fine, but I just didn't expect that by transitioning from v2 to v3. And is also the reason why I don't have much time to create 'simplified' projects of all these projects I bump into issues. Or at least I wait till it's really necesary. I try to isolate the problems myself in little projects though, but then everything still is (and needs to be) in a fully working development environment with webpack and all that. So that's a lot easier and less time consuming for me. That sounds like an improvement to me. Not sure though if this influences the usage of event functions like onUpdate() though. But guess that doesn't have an effect on it. Yes. See above. Your help is very much appreciated and yes, I'm using gsap a long time now with a lot of fun and enjoyment every time again and again. Moving to v3 is a little getting used to once, but is definitely a big step up. And I love the improvement in output filesize and the logical way it is setup. And as I wrote in my other thread, yes, I do have an active Greensock membership. And that's absolutely worth it. That way I am also able to use things like MorphSVGPlugin, which I happily do for years now. Looking forward to your reaction about the 'this' and the 'targets' (and maybe your thoughts on setting values to a DOM element not yet connected to the DOM, it would be nice to understand why setting transformOrigin on those work on 'all' browsers, but need different values, except for on FireFox where it's not working at all). Right now it looks like these things are the latest bump to understand moving things to v3 the right way with the projects I'm currently converting. Thanks a lot @GreenSock Jack, Zach etc.!

That's actually pretty nice indeed! Great to know

Yes!!! and OMG, you are completely right, I used getProperty() directly on the element instead of using the gsap object. And I even should have known/spotted it as I used getProperty() on other projects too now, but there the right way. Guess it's getting late, time to stop! ? So it's completely working as wished for now (and like the _gsTransform before, but better)! ? getProperty() is a great addition btw. Nice to have an 'official' public method for this. Thanks for your quick reaction @GreenSock Jack

Hi Afrowave, just a quick reaction, because I 'by accident' just read your post, because I saw 'Draggable' and version 3 and I'm converting draggable gsap v2 projects to v3 at the moment so I was curious; The draggable versions before gsap version 3 were already capable of using objects instead of needing to use IDs of DOM elements. Not sure if I misunderstood, but just so you know this was already possible. Just my 2cts so you know it's also possible in version 2 to do things like this.discEl = document.getElementById('disc'); this.draggableDisc = Draggable.create(this.discEl, { type: 'rotation' });

In an existing project (using gsap v2) there is a disc a user can spin around (using Draggable), but it can also temporary turn off Draggable and spin by 'itself' (using a tween). Currently I am upgrading gsap to v3 in this project (btw, this is not the project I wrote about earlier). Everytime the rotation of the disc changes (by user drag or auto rotate) another display updates accordingly. In version 2 I did this by getting the angle of the disc with reading out the _gsTransform of the js part of the DOMelement. Which was being updated by Draggable and tweens, so was always the right value, no matter how the disc was controlled (manually by a user, or automatic by tween). But that behaviour seem to have changed in v3. At first I replaced the code using _gsTransform (to get the rotation) by element.getProperty('rotation'). To find out the element doesn't have a rotation property. Well at least not at first before being animated by the tween once. Before (in v2) it did have a value with _gsTransform, because Draggable updated it. Looking in the documentation of version 3 I see Draggable has it's own ('readonly') .rotation property and that it updates perfectly when the user drags the disc. So that's perfectly usable, but only solves half the problem. Because that rotation value doesn't change when the DOM element is being controlled by a tween (and so gets in reality a different rotation value). So when the tween rotates the disc the draggable .rotation property stays on the last value draggable put it to. Which is clearly not right anymore. Ofcoarse I can solve this myself by keeping my own rotation value, which once updates itself by the .rotation property of the draggable object and another time by the (hopefully existing) getProperty('rotation') of the element when being animated by a tween. But that feels a little hacky to be honoust and I'm wondering if it would not be possible to update the .rotation value of the draggable object, or, better in my opinion, have the property of the element that can be requested with getProperty() update itself when draggable changes the rotation value of that element. So what I mean is; would it be possible for us somehow to request the real rotation value of the disc directly from the rotated element (meaning the javascript part of that DOM element) at all times? (so like in v2). So no matter if it's being controlled by Draggable or tween, we could alway rely on the rotation property of the element itself? Or @GreenSock if that's not currently possible, maybe add that functionality in the lib if not exising yet? Thanks in advance! BTW I read your reactions @GreenSock Jack. Thanks for that. I will react later. But for now just so you know: I do have a Club Greensock subscription. And ofcoarse I think Greensock and all your effort is worth that ? [edit] I forgot to add: I found some 'ThrowProps' in the documentation of version 3. But if I am not mistaken, all 'ThrowProp' has been renamed to 'Intertia' in version 3, right? Just to let you know, here's the link to the 'ThrowProps' I found in the documentation: https://greensock.com/docs/v3/Plugins/Draggable in case you'd like to change it.

Sorry Zack, I don't have the time for that. I'm upgrading projects to version 3 and this is all taking me way too long now. I'm working for days now to solve issues I'm having when just upgrading from gsap 2 to gsap 3. I thought this upgrade would be painless, but that doesn't seem to be the case. There are more things changed than I thought and I was also bumping into an issue of Draggable, and I did read the migration guide beforehand. I'm also starting to bump into other things right now, like scopes, staggerTo not working anymore (I know we can add stagger: {} to a .to(), but scopes are changed and also the targets in stagger-update-functions and so on which need a different approach in v3 in all these projects. Which is fine, but I didn't expect that because I got the impression by what I read about v3 that this transition should go seamless by just some renaming. Guess I was wrong or misinterpret that. Don't get me wrong, I understand the choices of v3 and it's a great upgrade. Just underestimated the transition and didn't expect issues to happen, because I never had that before with Greensock. That's all.

In a project using gsap 3.2.0 everything works fine in Chrome, MS Edge (the latest chromium version) and even IE11, but CSSPlugin is throwing a TypeError in Firefox only (Both in Firefox: 73.0 as well as in Firefox 73.0.1 64 bits, win 10). Because even IE11 is not showing any errors or warnings and everything is running fine this probably is only related to Firefox in combination with the _getBBoxHack function inside the CSSplugin. Firefox was not having this error when this project was using gsap v2. Because of this errof the project is not even running at all (holds on error) in Firefox, but is running in all other browsers as mentioned ? Could this be gsap 3 having difficulties in tweening cloned svg elements? (gsap 2 was not having those issues with this project) Looks like it to me, also see my other post of today where cloned elements are not working the same as the original elements anymore, while in v2 they were. Here's the stack trace:

Alright, everything is working now after in the end just a little change in the code to make it work with gsap 3. See conclusion below. BTW Having a single value in the transformOrigin property was a typo on my side I made when upgrading to version 3. So I did use two values in the original v2 version. Conclusion after all this: The transformOrigin needs to be set the same way in version 3 as in version 2. EXCEPT!!! When we clone a svg element with cloneNode(false) (and append it wo the same group as the original)!!! Than we need to set the transformOrigin specifically on the cloned objects too in gsap v3, which wasn't needed in version 2. But not only that, we have to set it to a different transformOrigin value; transformOrigin on the original element (not the clone): transformOrigin: `50% ${pointOriginTransform + pointHeight * 0.5}px` transformOrigin on the cloned element: transformOrigin: `0 ${pointOriginTransform}px` So the original element needs an offset of the radius of the circle, while the clone don't need that offset. To me this means that a cloned element which has a transformOrigin set by gsap on the original element (a svg circle in this case) before cloning, but its clone doesn't have the (same) transformOrigin as the original element. Whereas in version 2 it did have the same transformOrigin in the clone as the original and was therefor a real clone. This issue is there both with using gsap 3.1.1 as well as using 3.2.0. Could it be that gsap 3 is keeping values like transformOrigin inside javascript objects instead of inside DOM object-attributes and therefore don't come with the clone and got calculated differently or not at all? Anyway, this took me way too much time. And I have some more projects to upgrade, so glad this finally is working now.

I tried it with setting the gsap.defaults({ overwrite: 'auto' }) (and also setting it to overwrite: false, just to have tested that, but both don't make any difference. [edit] I have just narrowed the issue to the real issue here as it looks like: using transformOrigin on the original svg element (a circle) still needs the same calculation in v3 as in v2, so is unchanged. But after cloning that element with cloneNode(false) and setting transformOrigin on the clone (even when cloning before setting the transformOrigin to the original) has a different behaviour in v3 vs in v2. So for the original element needs to be set with const pointOriginTransform = wheelCenterY - pointCenterY + pointHeight * 0.5; But the clones of that element (which I created before setting this transformOrigin) behave differently, eventhough they are appended to the same <g> and need to be set with: const pointOriginTransform = wheelCenterY - pointCenterY; (So without adding the element's circle radius). So for some reason there is a difference between the original element and the cloned element.

Hello Jack, I understand that it doesn't make sense to you. If it would make sense to me I didn't have to open this thread, so we're on the same page Guess that's the life of a developer sometimes. Especially as a front-end developer. WIth the change in my calculation of the transformOrigin I feed to the transformOrigin property, changing the one-value transformOrigin to a two-value transformOrigin and using the 3.2.0 version where the Draggable issue is fixed, the project is almost working as it was with v2. Except for one tween inside the timeline for some reason. There the offsets of objects are off. If I have thatone worked out, the animation is working with v3.

Yes I tried that, but it wasn't necesary as the other way is the right way. Most of the steps in the animation now have the right locations after applying the change in calculation of that transformOrigin, which needed to be different in v3 than in v2. So the solution was as I described above. Only problem left is that one tween in that timeline somehow doesn't have the exact right offset when using gsap v3. I'm debugging that right now.

If I knew that that might be an answer to solve this issue here, right? ?

I know, but Javascript does: this.p[i] = this.p[0].cloneNode(false);

I appreciate your effort to help Zach. Yes, I know about the ticker and I use it to update graphics in canvas, threejs and so on if I use gsap in a project, but how would you like to control the speed and direction of the ticker in this case, where it would control a Spine-animation? In my opinion that's not possible with the ticker object. Even if we change the fps, which would affect everything else in the project I believe, which is obviously not what we want, then still it doesn't change the deltatime. But with a timeline we can play(), pause(), reverse() and so on and obviously yoyo was also working in v2. Also, when switching to a ticker, than we could as well just create a simple animationFrame loop, which fires at the same times normally. Again, eventhough the example might look weird to you, and I understand that, it worked in version 2 without a problem. I now solved it in this project by adding an empty timeline that's fine with me and I'm happy. Thanks for that tip. But I only hope it will keep on working in future updates than and not be 'fixed' so that with a later subversion it stopped working even with this extra empty tween.

I am debugging this right now and tried to start with a simpler project myself, but I'm afraid this is a problem that's happening with several things stacked together, so first I try to debug this myself a little, because making a 'reduced test case' doesn't seem to do the trick here at this stage. Findings I have so far: 1) In gsap v2 it was working to supply only one value to the transformOrigin property, like this: gsap.set(this.p[0], { transformOrigin: `${pointOriginTransform}px` }); gsap.set(this.p[0], { transformOrigin: `${pointOriginTransform}px` }); Not sure if that was a typo I created years ago which obviously worked in version 2 and so I never noticed this, or that this was supposed to work in version 2 as some kind of feature, but it's not working the same in version 3 anymore, so I changed this into having 2 variables: gsap.set(this.p[0], { transformOrigin: `0 ${pointOriginTransform}px` }); 2) It seems like gsap 3 is handling positioning of svg elements differently. Previously this was the calculation I had to set a transformOrigin: const pointOriginTransform = wheelCenterY - pointCenterY + pointHeight * 0.5; But in version 3 this needed to be changed into: const pointOriginTransform = wheelCenterY - pointCenterY; So it looks like gsap 3 is using the center of svg elements now and therefore I stripped the radius of the svg circle from the calculation in order to have the same result. So there is obviously something changed in gsap 3 according to transformOrigin vs version 2. 3) In the project I'm upgrading to gsap 3 now I use cloneNode to clone SVG nodes. In gsap version 2 I could set a transformOrigin with TweenLite.set() and after that clone that element and set a transform origin on the clone. And that worked fine when doing rotations after on both elements. But in gsap version 3 things don't work that way. So I needed to first clone the original element and only after that apply a transformOrigin to it. Or else the clone was somehow off in positioning/origin. As if gsap 3 is doing something destructive to the object where v2 was not or visa versa. 4) There is another problem I'm facing now, which seem to be related to rotating after setting a transformOrigin. The first time it works as exected (and as in version 2), but rotating again (in the same timeline) doesn't have the same results as in version 2. Sorry for being this vague, but I'm still investigating this. I can't share the project I'm working on I'm afraid and will try to create a reduced project when I find a way, but so far it all seem to be related; the cloning, the hierarchy of the SVG (working inside groups) and maybe even the Draggable plugin controlling the main group. So first I do some more testing here. But if according to what I wrote above you have some clues or suggestions on things that are changed in v3, that would be appreciated! Thanks again for your help.

Thanks for your help @ZachSaucier. You are right in that the timeline has a duration of 0 and I can agree with you on that that is one way of looking at this situation and therefor can be a logical choice to not start the timeline if it doesn't have tweens or a duration of 0. If the timeline didn't have a loop set!! So I'm afraid I have to respectfully dissagree on thisone. Because on the other side, it also makes a lot of sense to me to start and loop a timeline if it has an endless repeat applied to it and also an onUpdate() attached. And there is actually a pretty handy usecase for that; we can let the onUpdate() of this endless timeline move the playhead of a Spine animation (or whatever other frame-based animation using delta), so now everything is in the gsap environment and we can now use all available gsap controls, like changing the speed, reversing the animation and so on. And it's also synced with all the rest of gsap animations in the project. Your solution to add an empty tween to it works. Which is great and solves this problem in this project now. But isn't that conflicting the mindset of not starting a timeline when the duration is 0? So I'm not sure if I can trust this to keep on working this way in future gsap updates. IMHO I would say a timeline with a repeat on it should at least repeat. Because we put that repeat there on purpose. Actually what we have than is a requestAnimationFrame loop, but with full control by greensock (and all its plugins), and that's exactly what I'm after here. Being able to add an empty timeline to it is totally fine with me and works fine, but than I hope this capability will not be 'fixed' in a later gsap version, because at a later time Greensock might think this is wrong behaviour and needs to be fixed, in order to not let developers add empty timelines to it or don't run the timeline if the tweens on it have a zero duration.

Wanting to control a Spine animation with a gsap timeline, in version 2 it was enough to initialize a timeline on yoyo loop (repeat: -1, yoyo: true) and use the onUpdate() method to update the Spine playhead. But this seems not to work anymore in gsap v3. (converting a working project to v3) Gsap Version 2 (works: repeats endlessly): this.tl = new TimelineMax({ repeat: -1, yoyo: true, onUpdate: () => { const total = this.tl.totalTime(); const delta = total - this.lastTime; this.tree.update(delta); this.lastTime = total; }, }); Gsap Version 3 (doesn't work: only runs once): this.tl = gsap.timeline({ repeat: -1, yoyo: true, onUpdateParams: [this], onUpdate: (self) => { const total = self.tl.totalTime(); const delta = total - self.lastTime; self.tree.update(delta); self.lastTime = total; }, }); It seems like in version 3 a timeline without inner tweens stops after the first round, eventhough it's set to endless loop. Is this an issue in v3 or am I missing something here that has been changed in v3?

[also see my post before thisone, two posts in a row, but can't add these quotes to my previous post] It's starting to look like it, although I would not expect that from Greensock and it's also written in the v3 Migration guide. Thanks for helping by testing this. I'm using SVG btw and the group these objects are in (<g>) are also being used by Draggable to rotate everything around by the user interaction. So it looks like Draggable v3 is doing something different then Draggable v2 with the orientation/origins, or gsap in general handles origins (on svg) differently, or some setting is there now I don't know about (or it still has something to do with the smoothOrigin thing)? [edit] Disabling everything Draggable in the project is not solving the issue, so it looks like this is not Draggable related.

The Draggable issue I had in the other thread is solved with the preview of the latest Draggable (3.2.0) which fixed the issue. The origin problem I'm facing now is in the same project as that Draggable thing, but there's no issue on the origin problem of the <g> that's being rotated with Draggable, but with some other elements. That said, they are inside that <g> so it could be Draggable related. Since v3 these objects all have a different offset (SVG), which I had calculated and set with transformOrigin and worked fine in v2. So I figured maybe that smoothOrigin has something to do with it, because some default, calculation or setting obviously has changed in version 3 causing this different behaviour. There's something off with the origin now and this isn't a browser thing, as the previous version (working with gsap v2) still works fine.

I tween SVG/DOM elements in this case and use the documented general gsap.defaults() method. And as I wrote above, also tested this directly within the CSSPlugin (so also general/global), as written in the CSSPlugin documention. This is the documentation on defaults in the migration guide and I do exactly that: And this is the documentation on the CSSPlugin, and I tested exactly that: In this project I'm only having tweens on SVG/DOM elements. But there are places in this project where I tween on arrays of SVG/DOM elements with .to() which should also work (and I see it working, except for the origin problems I'm facing right now, which perhaps is related?) and always worked like that in v1 and v2. This is a project that's running for years now and kept up to date ever since, but somehow after only upgrading to gsap 3 (and adjusting all syntax to gsap 3) is having this issue. Arrays are allowed as target elements in version 3 still though, according to https://greensock.com/docs/v3/GSAP/gsap.to(): So maybe gsap is trying here to apply the defaults object to an array here and throws an error because an array is not an object in Javascript? I do some more testing

Using the smoothOrigin parameter in the gsap.defaults method (gsap v3.1.1) throws an error in the console: gsap-core.js:83 Invalid property smoothOrigin set to false Missing plugin? gsap.registerPlugin() These are my defaults: gsap.defaults({ overwrite: 'auto', smoothOrigin: false, }); I tried this with and without importing and registering the CSSPlugin, but there's no difference. Inside both the migration guide as well as the docs on CSSPlugin I see 'smoothOrigin' written like that. And I even copied the exact property just to be sure I didn't have a typo. But it doesn't matter, the error persist. I also tested the defaultSmoothOrigin property of the CSSPlugin directly. Setting the defaultSmoothOrigin property directly in the CSSPlugin doesn't throw an error, so at first glance it looks like that works, but that's because Javascript is just adding defaultSmoothOrigin as a new property to the CSSPlugin object there, as I can't find any 'defaultSmoothOrigin' property inside the CSSPlugin code and when printing CSSPlugin.defaultSmoothOrigin to the console without setting it the console shows 'undefined'. So this doesn't seem to work either: CSSPlugin.defaultSmoothOrigin = false; So somehow the gsap defaults() method doesn't seem to recognise the smoothOrigin property and the CSSPlugin.defaultSmoothOrigin property seems to be unavailable. Is this perhaps a known issue of the latest version, or inside the documentation and migration guide? or am I missing something here? https://greensock.com/docs/v3/GSAP/CorePlugins/CSSPlugin

Ah alright, that's great to know. So we don't need to import CSSPlugin anymore. And I see it's not even needed to register the CSSPlugin either anymore. Nice. Thanks for this welcome tip. I saw that video, but when it started talking about working with a <script> tag I stopped watching it, thinking this is a video for people not using bundlers. Yes, I know. I use MorphSVGPlugin elsewhere in the project and forgot to remove it from this code snippet. BTW adding Draggable and InertiaPlugin to the gsap import line in code, so like import { gsap, Draggable, ...} from 'gsap/all'; also seem to work. Question: Is there a special reason why you advise to import Draggable and InertiaPlugin on their own lines? Or are you just doing that for reading code purposes because you like it better that way? Question: And is there in v3 a difference between importing from 'gsap' and importing from 'gsap/all' (in v2 the advise was to import from gsap/all, is that changed in version 3?). Or maybe I should watch the full video ?. This problem is what I'm experiencing indeed. Thanks for this @OSUblake . The element I use Draggable on is indeed a <g> element. So it looks like that is the problem I'm facing now and I'm gonna look if it is fixed in the preview of version 3.2.0 you sent. Gonna try the 3.2.0 version today. I'll let you know if that fixes the issue. Thanks for all your quick responses so far. [edit] @GreenSock Yes, replacing Draggable with the 3.2.0 preview fixes the issue!

Just a thank you for all your hard work on version 3. Just spotted a 22% difference in filesize output between gsap v2 and gsap v3! Love it! ?