Lark Posted October 28, 2021 Share Posted October 28, 2021 Hello! I've been trying to utilize gsap to construct a certain tool, and I've run into the exact same problem in these thread: I'm currently using gsap 3.7.1. My case is very similar, where the draggable (and SVG element) is moved around, it's position is defined via transform, and there is another element which may affect this transform, so I need to use update(). Trying to gsap.set(element, {transform: 'translate(...)'}) works unexpectedly and sets the transform to all zeros. I would like to use the parseTransform functionality discussed in these threads but can't find the functionality in gsap 3.0. Does it still exist, or is there an alternative? I need the draggable to be up to date with the element's transform, otherwise it keeps snapping back. I would love to make a codepen example but I cannot for the life of me manage use Draggable in there, since it does not appear as a plugin on the gsap import from npm, so if anyone can direct me on how to do that I'd love to show an example. Otherwise if you understand my issue, by all means, I'd love some help. :) Link to comment Share on other sites More sharing options...
Cassie Posted October 28, 2021 Share Posted October 28, 2021 Hey Lark. You can add all GSAP plugins by searching in the 'Add External Scripts/Pens' panel Here's a starter for you See the Pen OJjgwMe by GreenSock (@GreenSock) on CodePen I read through those threads - On 1/14/2015 at 1:41 PM, Rodrigo said: Yep, the problem was simply that you were trying to manually change things via CSS, but for optimized performance, GSAP caches transform-related values internally (actually, on the element itself, inside a _gsTransform object), so it's always best to set them directly through GSAP, like TweenLite.set(element, {x:100, y:200}). Can you use x and y values directly like Jack suggested? Link to comment Share on other sites More sharing options...
Lark Posted October 28, 2021 Author Share Posted October 28, 2021 Hey @Cassie, thanks for the reply! So this is slightly awkward, but minutes after posting this I have indeed tried using gsap.set(... {x:..., y:...}) instead of trying to set the transform, and it worked like a charm. I still do not understand why trying to set the transform property to a string bugs out like that (or is that a feature?), and why setting the x and y like this doesn't clash with the existing transform. Edit: In this codepen one can see that trying to move the thing right by setting the transform property just sets everything to 0. See the Pen vYJZzjK by LarkRanger (@LarkRanger) on CodePen Link to comment Share on other sites More sharing options...
Cassie Posted October 28, 2021 Share Posted October 28, 2021 Awesome, glad you have it fixed! I can't see what you mean by 'bugs out' - But when transforms are defined as a string GSAP has to apply it to the element, and then read back the matrix that the browser creates, the aliases provided are faster and give you a consistent order of operation (CSS processes transforms in any order which can result in different outcomes) As Jack says in the snippet I linked to - GSAP caches transform-related values internally inside a _gsTransform object, (to avoid clashes) Maybe @GreenSock can shed more light on this but It's hard to understand what the issue was without seeing! Link to comment Share on other sites More sharing options...
Solution OSUblake Posted October 28, 2021 Solution Share Posted October 28, 2021 3 hours ago, Lark said: Edit: In this codepen one can see that trying to move the thing right by setting the transform property just sets everything to 0. As Cassie said, you should use x, y, etc instead of transform. If you really needed to change the transform orf an SVG element, which you shouldn't as it will mess stuff up with Draggable, you would need to change the transform attribute. gsap.to(".rect", { attr: { transform: "translate(70 70)" } }); 1 Link to comment Share on other sites More sharing options...
Cassie Posted October 28, 2021 Share Posted October 28, 2021 Ahh I missed that it was SVG - good spot Blake. Link to comment Share on other sites More sharing options...
Lark Posted October 28, 2021 Author Share Posted October 28, 2021 1 hour ago, OSUblake said: As Cassie said, you should use x, y, etc instead of transform. If you really needed to change the transform orf an SVG element, which you shouldn't as it will mess stuff up with Draggable, you would need to change the transform attribute. gsap.to(".rect", { attr: { transform: "translate(70 70)" } }); Thank you so much! As I said, I ended up using x and y instead of transform, but I did mark this as the resolution since it does answer my original question. Thank you very much for the help, this solved a massive bug for me. Link to comment Share on other sites More sharing options...
GreenSock Posted October 28, 2021 Share Posted October 28, 2021 Just to clear up a few things... When a "transform" gets applied to an element, GSAP has to apply it to element.style.transform and then read back the matrix and parse it into all the components, but you were setting it to an invalid CSS transform, "translate(70 70)" instead of "translate(70px, 70px)", thus it broke when being applied. Like Blake said, it's always best to use the shorthand components like x and y because not only is it faster (no need to do all that parsing of the matrix), but it's more accurate in some cases because matrices are inherently ambiguous with rotational values. For example, the matrix for 90 degrees is the same as the one for 450. rotation of 180 is the same as rotation of 0 with scaleX of -1. It's just messy which is why GSAP caches things to keep them nice and clean. For SVG elements, GSAP applies transforms to the "transform" attribute instead of the CSS style because several browsers have bugs with the way CSS transforms are applied to SVG. We also bake the transformOrigin into the matrix to work around browser bugs. So be careful if you apply a CSS transform directly because then the browser can end up with conflicting values in CSS and the attribute, and some browsers prioritize CSS, others prioritize the attribute. 🙄 There is no _gsTransform object in GSAP 3. That's from the old v1/v2 days. If you need to get a value, just use gsap.getProperty(element, property) Glad to hear you got things working now. 👍 1 Link to comment Share on other sites More sharing options...
Lark Posted October 28, 2021 Author Share Posted October 28, 2021 You 1st point is rather interesting. Though I do see the error of not specifying px, and maybe this is me completely misunderstanding SVGs, but in the original rect tag I do specify translate(20, 20), so what's that? Is that value translated to px by gsap? Either way thank you so much for the clarification! Link to comment Share on other sites More sharing options...
OSUblake Posted October 28, 2021 Share Posted October 28, 2021 There's a difference between animating the transform attribute on an SVG and animating the transform style. SVG elements can be a little confusing because presentation attributes can also be styled with CSS. The first way you were trying to do it was animating the style, but the syntax you used is invalid. It's a CSS thing. You can test it out by adding the rule to your CSS. // bad .rect { transform: translate(300 300); } // good .rect { transform: translate(300px, 300px); } 1 1 Link to comment Share on other sites More sharing options...
Recommended Posts
Create an account or sign in to comment
You need to be a member in order to leave a comment
Create an account
Sign up for a new account in our community. It's easy!
Register a new accountSign in
Already have an account? Sign in here.
Sign In Now