Greensock and Responsive Units?

[Creek]

I greatly apologize - absolutely brand new, haven't even dipped my toes into GSAP yet -

 

But, in hunting info as questions pop up in my head, there's often mentions of older GSAP and the current version? As in this feature doesn't "currently" work, but it will likely work with the new version?

 

I doubt that linked quite correctly - but Jack responds in the linked thread that the logic behind viewport units creates issues for whatever various reasons? I'm not pretending to understand what it is he's communicating? EDIT: I've tossed an "x" in here to the shareable link with his direct reply:

 

xhttps://greensock.com/forums/topic/18252-prevent-gsap-from-transforming-my-transforms-into-matrix/?tab=comments#comment-84205

 

But say you have an svg centered in the viewport or a grid area, and wish to move it around - pixels aren't very helpful, because the object's size is relative.

 

So I was just wondering if the current version of GSAP work with these units - rather than 300px to the right, possibly 20vw or 20%? If so, is there possibly a codepen where these units are being used rather than pixels for at least some of the basics - scaling, moving - where I could possibly play around with it by resizing the viewport and see what the effect might be? Also, to see how I might implement those units within the script, if different than the x and the y pixel units?

 

Just very much hoping GSAP is as easy to use once I shed the pixels? And, if there are some calculations for movement in a 2D space, hopefully someone might offer up how that would work instead - where some other javascript maybe quickly measures the container and then fills in the variables or whatnot? Again, talking way over my head. 1fr might be 650px or 500px or whatever, clamped at 300px and 900px? I have no clue - but I'm pretty sure x and y in pixels won't work too well with the relative animation?

 

Thanks very much for any help!

 

[GreenSock]

3 hours ago, Creek said:

So I was just wondering if the current version of GSAP work with these units - rather than 300px to the right, possibly 20vw or 20%?

GSAP 3 was a complete rewrite that was launched back in 2019 and one of the improvements we made was adding support for non-px units on x/y transforms of regular DOM elements. So yes, if you're talking about animating the translation of an <SVG> element, you're golden. But if you're talking about SVG elements like <rect>, <path>, <circle>, etc., those are inside the SVG's coordinate space which is very different altogether. That's not a GSAP thing - that's just how SVG coordinates work. 

 

3 hours ago, Creek said:

Just very much hoping GSAP is as easy to use once I shed the pixels

Absolutely. Once you get past the initial learning curve, you're gonna feel like you just got animation superpowers. Like when the spider bit spiderman...so prepare yourself

 

There are also xPercent and yPercent transforms which you can even layer on top of standard x/y for cool effects.

 

If you still have questions, I'd strongly recommend creating a minimal demo on CodePen or something and let us know what you're struggling with. It's always best to have something we can look at in order to understand the context. Here's a starter template you can fork - it has ALL the plugins loaded so you can go nuts: 

See the Pen aYYOdN by GreenSock (@GreenSock) on CodePen

 

Happy tweening!

[Creek]

THANK YOU!!! Definitely looking forward to the experience!

[sparker888]

Thanks for bringing this up , Creek. I'm somewhat new to GSAP as well. I have completed several courses and just completed my first site with GSAP. It's fantastic, but I have a lot more to learn!

This topic is one area I struggled with, but most of my issues were resolved with xPercent and yPercent as Jack mentioned. Another trick was to add overflow-x: hidden in CSS to prevent the horizontal scroll bars from showing up when you move elements off screen.

I'm looking for more GSAP Responsive best practices. I've searched, but only found bits of info here and there, and there's a lot of outdated info related to older versions of GSAP which makes things somewhat difficult. A section on this would be nice.

[Cassie]

Adding that one to the article backlog 👀

[OSUblake]

19 hours ago, sparker888 said:

I've searched, but only found bits of info here and there, and there's a lot of outdated info related to older versions of GSAP which makes things somewhat difficult

 

Do you have links to some of the stuff you thought was outdated?

 

GSAP 3 is compatible with like 99% of the old syntax, but of course it would be better to migrate to the new syntax.

 

Probably the biggest breaking change you might see in older code is stuff that references _gsTransform, which is now handled by gsap.getProperty.

 

[sparker888]

9 minutes ago, OSUblake said:

 

Do you have links to some of the stuff you thought was outdated?

 

I looked to see if I had bookmarked anything, but I did not. I just made notes along the way. I'll keep an eye out though. It's nice to know that there's not any major break though. A lot of this is me just getting use to the syntax and design patterns. I'm getting there!

[Creek]

31 minutes ago, OSUblake said:

Do you have links to some of the stuff you thought was outdated?

 

Simply just coming at this as a complete noob, all of the old stuff is "outdated" in that I make the poor assumption that there's now a better "new" way? Whenever I even run across code for the previous version, I just assume it's outdated?

 

For instance, if I have a problem with my computer and run across a solution where someone supplies a terminal command, I MIGHT give it a shot if I can't find a more "current" solution? But I basically have little to no faith that it'll actually work.

 

There's probably already a guide on here - or even just the basic familiarity - that allows most folks to just naturally understand how old GSAP code and the new GSAP go hand in hand?

 

But, again - just tossing my idiocy out there - we try to steer clear of old HTML code like floats, etc. - because we now have Flexbox and Grid, etc? So my initial assumption is that old code is pretty much all archaic?

 

As I'm learning, I pretty much always append the current year when searching for info - not within Greensock's forums so much, but definitely on Google, YouTube, etc? Everything's been moving so quickly that - again - I just make the poor assumption that the vast majority of old code is likely only going to throw me for a loop?

 

 

[Cassie]

There's not a huge amount of changes syntax-wise to be honest.

It's more like 'cool new additions' than an entire new way of writing GSAP code.

99% of what you'll need to change is the following
 

// old 
TweenMax.to(".class", 2, {x: 100});

// new
gsap.to(".class", {duration: 2, x: 100});

// -- Timelines --

// old 
var tl = new TimelineMax();

// new
var tl = gsap.timeline();

You can read more here -
 

And in our docs there's a v2/v3 toggle in the menu to make sure you're always getting the latest info!

[OSUblake]

12 minutes ago, Creek said:

For instance, if I have a problem with my computer and run across a solution where someone supplies a terminal command, I MIGHT give it a shot if I can't find a more "current" solution? But I basically have little to no faith that it'll actually work.

 

I get the feeling, like on StackOverflow I usually try to find the newest solution thinking it will be better, but that's not always the case.

 

14 minutes ago, Creek said:

There's probably already a guide on here - or even just the basic familiarity - that allows most folks to just naturally understand how old GSAP code and the new GSAP go hand in hand?

 

The Migration Guide is a good place to start.

 

 

15 minutes ago, Creek said:

So my initial assumption is that old code is pretty much all archaic?

 

Yes, sometimes it's like that because code is always evolving and getting better over time, but the core logic of how GSAP works with Tweens and Timelines has been the same for well over a decade. GSAP 3 just introduced a more refined syntax because the old syntax was confusing a lot of people, like what's the difference between TweenLite and TweenMax. 

 

 

[sparker888]

23 minutes ago, Creek said:

 

Simply just coming at this as a complete noob, all of the old stuff is "outdated" in that I make the poor assumption that there's now a better "new" way? Whenever I even run across code for the previous version, I just assume it's outdated?

 

 

Haha! I've gone down so many dead-end rabbit holes in my coding career, I'm very careful about implementing outdated code and techniques. So much so, that if an article doesn't have a date on it, and it's not clearly new standards, I stop right there and then. This migration guide helps!

[Creek]

6 minutes ago, sparker888 said:

Haha! I've gone down so many dead-end rabbit holes in my coding career, I'm very careful about implementing outdated code and techniques. So much so, that if an article doesn't have a date on it, and it's not clearly new standards, I stop right there and then. This migration guide helps!

 

Exactly this. No, wait... sorry - this.exactly? Nope.... => Not this then? Or else!

 

Completely an aside - but it's funny to me that every JavaScript Introductory course relates that Javascript is NOT Java. As if I know what Java is? And then they explain how Javascript is now its own programming language. It's apparently very exciting!

 

Possibly being too honest - again, just tossing out my noob experience - I'm quite certain I probably should care, but I don't.

 

And what makes GSAP so incredibly appealing is that I don't need my PhD in Javascript.

 

27 minutes ago, Cassie said:

There's not a huge amount of changes syntax-wise to be honest.

It's more like 'cool new additions' than an entire new way of writing GSAP code.

99% of what you'll need to change is the following
 

// old 
TweenMax.to(".class", 2, {x: 100});

// new
gsap.to(".class", {duration: 2, x: 100});

// -- Timelines --

// old 
var tl = new TimelineMax();

// new
var tl = gsap.timeline();

 

 

Just that very little bit immediately pulls me out of a major tailspin.

 

Again, if this is of the slightest interest to anyone other than myself - I'm still in the middle of just "exploring" everything. And, given I'm not migrating from an older version - I suddenly NOW read that as "Oh - I can read the Migration guide and then I can possibly understand older forum posts."

 

And they suddenly now have value - because

 

31 minutes ago, OSUblake said:

 

I get the feeling, like on StackOverflow I usually try to find the newest solution thinking it will be better, but that's not always the case.

 

31 minutes ago, OSUblake said:

Yes, sometimes it's like that because code is always evolving and getting better over time, but the core logic of how GSAP works with Tweens and Timelines has been the same for well over a decade. GSAP 3 just introduced a more refined syntax because the old syntax was confusing a lot of people, like what's the difference between TweenLite and TweenMax.

 

So, again again - THANK YOU!!!!!