akapowl

That is because you have a huge margin-left set on the .pinWrap via CSS which is not included in any way within the values you are currently using and you never add it to your calculations in any form. If you'd do so, it'd work just fine.

I multiplied it by 2 here so basically it will end up with the same spacing on the right now when the tween is finished.


See the Pen zYXKbyJ by akapowl (@akapowl) on CodePen

 

Hello there. The documentation has the answers to your questions.
 
1.   You'll want to look for the scroller property.

https://gsap.com/docs/v3/Plugins/ScrollTrigger/
 


2.   No, unfortunatelly it is not possible for ScrollSmoother to have it smoothen the scroll of a different element than the body.

https://gsap.com/docs/v3/Plugins/ScrollSmoother/#faqs
 
 

TLDR:
At the bottom of the post you'll find an example for how you could approach it.
Nonetheless, I think reading through all this can help get a better understanding.
 

I think that would definitely be the best way to go, if you want a solid answer - because what you are asking is heavily about how three.js works to begin with.

My attempt at a short answer would be: you can not easily do that in a way that it would logically work the same as e.g. changing the object.rotation.y does.

And here is why (please keep in mind that I am no full-fledged expert with three.js though):



While object.rotation.y (or x or z) is a 'property' of your 3D model that three.js gives you access to, you can easily set it - e.g. by tweening on it via GSAP.

object.geometry.rotateY() on the other hand is a method - it is a function you can execute on that object, where internally three.js will do all the work with the value provided by you. So for starters it is not a simple value you can easily manipulate via GSAP.


See the Pen ZEPgYLP by akapowl (@akapowl) on CodePen


As you can see in the codepen above, technically of course you can tween a value you set up on an object of your own via GSAP and onUpdate of that tween call that method provided by three.js  - but:
  a) it will not work in the same way as tweening on the object.rotation.y in the same way would - because you are only providing a value to another pipeline (i.e. the rotateY method of three) which then again does different things with it. With some trickery around the tweening on the value you sure could settle on similar behaviour - but that would really be logic for you to figure out.

Just for illustration purposes, here is that same tween (albeit with different numbers) on the object.rotation.y value to show how it behaves different.

See the Pen vYPoNyq by akapowl (@akapowl) on CodePen


Now in the first pen you could e.g. get a similar effect of yoyo-ing back and forth between the two values by simply using a linear ease or an ease that goes in and out - so you see it is not impossible to achieve similar behaviour. I'm just saying that because of that extra pipeline you'll have an extra layer of abstraction and complexity added to how you'll have to approach things, which would be all yours to figure out in the process.

Still I wouldn't really recommend doing that though, because...
  ...probably even more importantly b) You probably should not really consider doing that all that much to begin with. What three.js does under the hood of that method is to calculate the position of every single vertex of your model; as this answer on a stackoverflow post mentions:

https://stackoverflow.com/questions/71506350/three-js-set-absolute-rotation-of-sphere-rather-than-cumulative-rotation#answer-71506597

That can already be taxing with simple 3D shapes, but depending on the level of detail of your model(s) this can become rather hefty rather quickly.
   
You can certainly access and manipulate the values neccessary to do that in different ways in JS already - like e.g. by using three's BufferGeometry instead three's provided 'pre-made' geometries, but even then the calculations would be quite a bit  more complex than just setting one single value somewhere. And since you say you are loading a .glb model, that will very likely not be a way to go for you anyway.

Another way you could think about doing it would be to use a shader that you provide with a value you tween on via GSAP. That would probably be a whole lot better with regard to computation cost because you could outsource all the calculations based on that value to the GPU, but it would also be a whole new world you'd open up outside of JS - and the complexity of the calculations would still stand on top of that.

So yeah, depending on the level of control you want to have over what you're doing, personally - with my limited knowledge about three.js - I don't think what you are aiming to do is as easy as you might think. But maybe I'm totally off track somewehere here, and the folks over in the three.js forum can provide you with some better input and an easy solution.

If so, it would be great, if you'd post back here with what you found out. Good luck!

----

Edit:

Alright, I played around with it a bit now, and have now stumbled upon an oversight logic-wise, that has a huge effect on how things behave.

In the first example above, I am just providing the value I am tweening on to three's .rotateY method, which does cause the appearance of 'no control' because every tick I am basically telling three.js: 'add that value the tween is currently at to the rotation'. So along the tweens duration, the rotation would add up more and more and get vastly out of what I wanted it to be.

An easy way to fix that is to keep track of the rotation value in an extra variable that I called oldValue in the pen below. Now in the onUpdate callback, I subtract that oldValue from the value the tween is currently at when passing it to three's .rotateY method. And after that, I set this oldValue to the value the tween is currently at.

This way I can make sure that every tick only the difference between the previous tick and the current tick will get added to the rotation.

And now it behaves just like the example with tweening on the object.rotation.y does.
 
Note, that I am now also using three's built in MathUtils.degToRad, so instead of just some arbitrary values, I can work with to me far more familiar degrees instead of radians.

But for the aforementioned reasons with regard to it having huge potential for killing performance, I probably still wouldn't really recommend doing that. Maybe thiss will help you out, though.


See the Pen qBvebOB by akapowl (@akapowl) on CodePen

 

The place it tweens to is actually not random at all in your case, but exactly what you tell it to.

In your current case with feeding in an object of x:0 and y:0 to the convertCoordinates method what you will get in the end is the distance of the dragged element to your point element on both axis anytime you release - but then to your tween you're feeding those as absolute values, so it will always tween to that absolute point from the draggables origin - try getting very close to your point and you'll see that you'll end up very close to where the dragging originated. Or alternatively just log the values and compare them with the values of the transformMatrix on the element after the tween is done - logging values is a always a huge help with identifying your problems, btw.

So I see two ways you could go about this:
 
Keep the object at {x: 0, y: 0} but instead of using absolute values for your tween, use relative values like x: "+=" + point.x

See the Pen XWQXaLa by akapowl (@akapowl) on CodePen



  Keep your tween at the absolute values, but instead feed an object of the current coordinates of the draggable object to the convertCoordinates method - something like {x: this.x, y: this.y}

See the Pen yLrezgX by akapowl (@akapowl) on CodePen
 
 
 
I will say, that since I never had the need for that method before myself, I can't give you much of a guarantee for any of the two ways to be the right way to go - and if something is inherently wrong with what I suggested, I'm sure someone with some more experience on that will pop in to help out.

While version 2 to me feels like it's more in line with what the documentation says about the object you feed into the convertCoordinates method;
 

... after a bit of tinkering, it also feels like version 1 seems to work more reliable with quick drags and releases. In general though, both versions should work in your current case; but one might be better or worse suited for you when extending your usecase. I hope this will at least help in some way.
 

Looks like Mitchel was right 👍- for that you really wouldn't need an onReverse callback.

Here's just two ways you could handle something like that - and there's probably a couple others beyond those.

I hope these will be helpful already, though:
 
Depending on the index of the dot (to make sure neither the first nor the last will get toggled at the end in any direction), you could .add() functions before and after each of your tweens to toggle the class .

https://gsap.com/docs/v3/GSAP/Timeline/add()/

See the Pen yLwxXgX by akapowl (@akapowl) on CodePen

  Or (even better) with similar logic with regard to the index, have things handle via GSAP altogether with .set() calls; unless you really need that active class, like maybe for something else outside of the pure styling.

https://gsap.com/docs/v3/GSAP/Timeline/set()

See the Pen yLwxXMX by akapowl (@akapowl) on CodePen

 
Some hints with regard to syntax:
 
// Instead of this: tl.to(dot, { rotate: "180deg" }) // You could just do this: tl.to(dot, { rotation: 180 })
https://gsap.com/docs/v3/GSAP/CorePlugins/CSS

Also there is no such ease as 'linear' - if you want linear interpolation, ease: 'none' is what your looking for.

If I am not mistaken, any invalid ease like that would fall back to the default ease of 'power1.out'.

Edit:

It looks like 'linear' seems to be accepted though, and will result in no easing 🤔
And apparently that is the case since like forever in GSAP3 ...didn't even know that 😅

https://gsap.com/docs/v3/Eases/
 

That's probably mostly a concern of your CSS styling and nothing GSAP related.

Your cursor is set to position: absolute  - that will be in relation to the body in your case.

The page keeps on scrolling vertically, even if you fake a horizontal scrolling movement.

Thus you cursor will also move up as it keeps scrolling with the body.

The easiest way would probably be to just set it to position: fixed isntead.
 

As the GSAP Helper already mentioned, without a minimal demo it is close to impossible to tell for sure, but my best guess would be that you are using some CSS fraework like probably tailwind, judging from the classes on the element you are animating with GSAP.

If that is the case, here's what tailwind'stransitionclass will add via CSS

https://tailwindcss.com/docs/transition-property
 
transition-property: color, background-color, border-color, text-decoration-color, fill, stroke, opacity, box-shadow, transform, filter, backdrop-filter; transition-timing-function: cubic-bezier(0.4, 0, 0.2, 1); transition-duration: 150ms;
So my guess is that you have CSS transitions fighting with updates on the element done by GSAP.

On properties of elements that you are going to tween on with GSAP, you should never have transitions applied.

This older demo of mine illustrates why.


See the Pen JjmrMNy by akapowl (@akapowl) on CodePen

 

Hello there.

Here are the problems in your pen that are responsible for it not working:
 
You are gettting an error in console - there is no such thing as SmoothScrollbar.init() - it is Scrollbar.init() instead; nothing related to GSAP.

Also, as far as i know, smooth-scrollbar does not have an 'effects' property; so that is probably redundant, too. I would suggest removing that to prevent any possible problems that might arise from that.
  You don't have a layout/setup that would work with smooth-scrollbar to begin with; you'll need to apply proper CSS styling on the body and the container you're going to initialize smooth-scrollbar on for it to work; nothing GSAP related.
  In CSS as well as in JS you are targetting elements with the class '.item' but you don't have any such elements in your HTML, you only have '.item-1', '.item-2' and '.item-3'; nothing GSAP related.
  Your .item element has a height of 0 set via CSS. Although in a comment you say you're going to set its height via GSAP, you never do.
Again, less of a GSAP specific problem.

And finally:
  You are not declaring a specified scroller element in your ScrollTrigger, which you will have to do, as smooth-scrollbar does not run on the body element. This one is something GSAP / ST specific; 

For clarity, see the smooth-scrollbar example and documentation on

https://gsap.com/docs/v3/Plugins/ScrollTrigger/static.scrollerProxy()   
Since a lot of your problems arise from not properly handling smooth-scrollbar in the first place, I would suggest having a thorough look at their documentation. Smooth-Scrollbar is not a GreenSock product, so you really shouldn't expect to get support for it in the GSAP forum.

I implemented the raw basics to the fork of your pen below - and it works as it should.

I give no guarantee that it is bullet proof with regard to smooth-scrollbar though; you should check on all that yourself.

https://idiotwu.github.io/smooth-scrollbar/

https://github.com/idiotWu/smooth-scrollbar
https://github.com/idiotWu/smooth-scrollbar/blob/develop/docs/api.md

Hope this will help get you going in the right direction though. Good luck!


See the Pen KKERaYE by akapowl (@akapowl) on CodePen

While you certainly can add those calculations to the start for each of your ScrollTriggers within that pinned element as shown above by Mitchel, actually you do not have to do that. ScrollTrigger does have a built in property to do exactly that for you in cases as such: pinnedContainer
 

https://gsap.com/docs/v3/Plugins/ScrollTrigger/

So the demos below with that property on the ScrollTriggers set to the pinned wrapping element should technically behave exactly the same as those with the calculations for the start shown above.

As I see he's been sharing that one demo a couple of times before, I'll also ping @Rodrigo just to make him aware. Of course there's absolutely nothing wrong with calculating things like that, it's just a different way to achieve the same result - but why do it when you can also let ScrollTrigger handle itself [Edit: except for maybe edge cases where you'd have to add some calculations anyway]. 🙃

See the Pen mdoxqNL by akapowl (@akapowl) on CodePen


See the Pen MWxVrgw by akapowl (@akapowl) on CodePen


 

I don't think that is a ScrollTrigger problem to be honest - but more an issue about how display: contents works in the browser.

If you set the start of your ScrollTrigger to something like '100px top' instead of 'top top' (because in your case it already has hit that spot thus the onEnter will not fire when starting to scroll) and inspect it in your browser's dev-tools, you can see the properties on it inline being changed as they should. So ScrollTrigger does exactly what it is supposed to do.

But:
 

Source:

https://medium.com/@zylberberg.jonathan/what-is-css-display-contents-property-and-how-it-can-solve-some-interesting-problems-4fdff7363777

Since that is the case, i.e. it not generating any boxes, you won't be able to set most properties on it; neither via CSS nor via JS.

Here is an example without any GSAP - neither the CSS opacity: 0, nor setting it via JS will do anything.

So I'm afraid you will have to re-think your approach on the styling of your layout a bit.


See the Pen QWoqZxP by akapowl (@akapowl) on CodePen


 

Hello there.

This forum is actually meant for GSAP specific questions - like e.g. about the API etc. - Everything you mention really just are CSS styling issues though.

If you want to know what's causing that huge vertical overflow, uncomment the 'backface-visibility: hidden' on your boxes and you will see that the perspective is sort of odd (I scaled your .stage down in this example so it becomes more apparent on first look), so you might want to change your perspective value.


See the Pen mdowBrG by akapowl (@akapowl) on CodePen



 
To change that, you will need to position your boxes properly within that perpective - that is within the container that holds the perspective.
So to make it look 'symmetrically tilted' for bottom and top, logically they will need to be in the vertical center of the element that has the perspective.

Here is your example with all that (and some more CSS styling on nav and body) changed.


See the Pen WNmOZRe by akapowl (@akapowl) on CodePen



  If you are having problems understanding how to work with 3D transforms to set things up as you wish in the first place, I would suggest having a look at this guide for example.

https://3dtransforms.desandro.com/



And since I mentioned it earlier, here's one thing about the GSAP API;

You don't need to wrap everything in a css object inside the vars object; you can just target the properties directly in the vars object like so.
 
// no need to do this gsap.set(stage, { css: { perspective: 1800, transformStyle: "preserve-3d" } }); // you can just do this instead gsap.set(stage, { perspective: 1800, transformStyle: "preserve-3d" });
But I'll leave it up to you to change that in your codebase.

Cheers.
 

Welcome to the forum, Simon.

You can disable automatic rounding via autoRound - that should help.

https://gsap.com/docs/v3/GSAP/CorePlugins/CSS#autoround


See the Pen ZEPGRNa by akapowl (@akapowl) on CodePen

Welcome to the forum.

These threads should help with that.
 
 
 
 

Hello @m4g1c14n

I've tinkered a bit with your demo, and it might be more of a general issue with numeric scrub values in combination with snapping - not just limited to clipPaths. Here is a demo minimized down even further.

The 'odd' behaviour seems to have been introduced with version 3.12.3.

See the Pen yLwBKJr by akapowl (@akapowl) on CodePen




Before (version 3.12.2 here) there was no flickering.

See the Pen eYXOMGY by akapowl (@akapowl) on CodePen

 


I'm sure @GreenSock will have a look into this as soon as he finds the time.

In the meantime you could either try moving down to version 3.12.2 for now, or alternatively set things up with a scrub of true instead of your numeric scrub; since the scroll on your example is being smoothed already anyway.



Steps to reproduce:

Scroll down past or into the gray section - scroll back up and stop scrolling to let it snap.
 

snap_scrub.mp4  
 

It totally does start at the right time; exactly as you set it up to.


See the Pen GRzVRPe by akapowl (@akapowl) on CodePen




The 75% you mention probably relate to the scaleY of your #id at the time the second tween starts, right?

That's because there is a default ease of 'power1.out' on every gsap tween. Since the scaleY increase won't be linear over the 2 seconds, you couldn't expect it to be 0.5 (or 50%) when the second tween starts (at one second into the first tween).

This is that same demo with an ease of 'none' applied - and now with a linear ease of 'none' you'll see the value be around 0.5 (or 50%).

See the Pen YzBmzgJ by akapowl (@akapowl) on CodePen

   

Here for example is one place where it is mentioned in the docs:

https://gsap.com/docs/v3/GSAP/Tween/#notes--tips

If you want to keep any type of ease but a linear 'none' and still know when a tween will hit a certain value (like you wanting those 50% or 0.5) so you can set up something to start at that point then, you'll want to have a look at this helperFunction in the docs - it should totally help with that.

https://gsap.com/docs/v3/HelperFunctions/helpers/easeToLinear/


[Edit] Oh, and I forgot to mention earlier:

If you're going to change the dimensions of an element, best don't use it as the trigger element for a ScrollTrigger; that will just throw things off for you in the long run - better wrap it in a div and use that wrapper as the trigger then.
 

I don't think you are supposed to add it to the usual Lenis setup, but use it instead of the usual Lenis setup.

When you add a simple console.log() of the direction in the onUpdate callback, you'll notice that the direction will flip from -1 to 1 to -1 to 1 [ and so forth] constantly.


See the Pen jOdRRzK by akapowl (@akapowl) on CodePen


That likely is the case because you call lenis.raf() in two ways over and over 'at the same time' - don't do that, you are creating conflicting behaviour.

If you just remove the usual call of the lenis.raf(), you'll see it work as it should, right?

I'm not too familiar with Lenis, but I think that should help; I hope it does.
  // Don't use this portion anymore when you add the lenis.raf() to the gsap.ticker function raf(time) { lenis.raf(time) requestAnimationFrame(raf) } requestAnimationFrame(raf)

See the Pen JjxVVMP by akapowl (@akapowl) on CodePen

Welcome to the GSAP Forum, @TezzyBear
 
 
One very simple way to achieve that the end position gets updated is to use vw/vh values for the x/y properties of your tween .
 

See the Pen OJdaewQ by akapowl (@akapowl) on CodePen
 
 
 
If you'd want to line up the center of your element to the center of the window, you could additionally also use xPercent/yPercent values on top of that.


See the Pen abXQgRv by akapowl (@akapowl) on CodePen
 
 
 
As  Toso already implied, it always helps to add a minimal demo to your question, so a) it becomes clearer what you actually intend to do and b) people willing to help don't have to go through the extra-steps of creating some themselves to show you what you could possibly do.

I hope that will help.
 
Edit:

If (for whatever reason) you can not use vw/vh values, another way to go about that would be to use function based values for your x/y properties, and in a resize eventListener function handle the progress of your tween and invalidate it, as suggested by OSUBlake in that older thread linked below, e.g.
 

See the Pen wvNQVaQ by akapowl (@akapowl) on CodePen
 
 

Hello @Gnekr

That SVG looks very much like the SVGs in these other threads a couple of weeks ago.
 
 
 
As was already mentioned in those threads, what you're trying to achieve is entirely possible, but will not be simple at all, which is why that is quite a bit out of scope of what to expect as support from these free support forums; especially if you do not provide anything you have tried yourself that we could offer hints or advice on - please read the forum guidelines.

Key to getting something like you intend done, is understanding how SVG works in the first place, so you can then go on and tinker with values that might be relevant for your expected animation goal.

https://developer.mozilla.org/en-US/docs/Web/SVG
 
There will be many, many things you will have to keep an eye on, so if I were you, I would start simple and work my way up the complexity from there. With regard to how exactly you want things to behave it might be better to re-work your SVG so it's easier to manipulate to get the exact effect going, that you aim for (as also mentioned in the linked threads).

Below is a rather basic example just to help get you started with something - not intended to serve as a working solution for you.
 
Note:
I used the .getBoundingClientRect method to get the dimensions I need to map to the SVGs dimensions, just because it works for me.
This likely might not work for your setup, and you may have to use some other way to determine the dimensions you need to work with.
 
https://developer.mozilla.org/en-US/docs/Web/API/Element/getBoundingClientRect


See the Pen eYxRovy by akapowl (@akapowl) on CodePen
 
 
 
What will probably come in handy, is having a look at GSAP's utility functions, especially mapRange.
https://gsap.com/docs/v3/GSAP/gsap.utils/
https://gsap.com/docs/v3/GSAP/UtilityMethods/mapRange()
 
I didn't use it in my example, but you could also have a look at GSAP's Observer, as an alternative to the plain eventListeners I used...
https://gsap.com/docs/v3/Plugins/Observer/

...and GSAP's .quickSetter() or .quickTo() for setting / tweening the values on mousemove.
https://gsap.com/docs/v3/GSAP/gsap.quickSetter()/
https://gsap.com/docs/v3/GSAP/gsap.quickTo()/
 
Also it might help in the long run for getting a better understanding of how to animate SVG to have a look at
https://www.motiontricks.com/

I doubt you will find an exact example of what you're aiming for there, but it offers some neat tutorials and great general advice on how to best work with SVG when animating.
 
Beyond that, if you have any questions directly related to GSAP, also please keep it simple instead of listing a bunch of requirements that you expect others to provide a full-fledged solution for. This forum is not intended to give out custom crafted code examples to anyone asking for it, but to help with problems encountered when using the tools provided. Stitching the little pieces together and developing the logic behind that to achieve your goal, will be yours to do.

And as also mentioned in the other threads already;
If you see no way to achieve something like that yourself, you might want to explore paid consulting options with GreenSock by reaching out to them directly,
or as an alternative you always have the option to post in the "Jobs & Freelance" forum to try and hire someone else that can help you with your tasks.

Good luck with the project!

Edit:

Here's that same example using multiple paths, just to give you a better idea for your more complex scenario.


See the Pen QWYgeXO by akapowl (@akapowl) on CodePen

 

Hello there @torry - welcome to the GSAP forum.

That is nothing really GSAP related - more like a styling issue you're encountering.
 
Your problem is, that the picture sits on top of the nav and thus blocks pointer events to go through to elements below it (on the z-axis). [ Edit: to be precise, it's not the img itself, but the wrapping div.pic1 ]

You can visualize that easily by right clicking where that link is that supposedly doesn't work, and then in the context menu click 'inspect element' (or something along those lines) to inspect the page in your browser's dev-tools.
 


A way to solve it would be to boost the z-index of your nav via CSS.
Don't forget to also set a position for the nav to make it work in the first place.
 
https://developer.mozilla.org/en-US/docs/Web/CSS/z-index
 
Something like this. I hope that'll be helpful.
 

See the Pen QWYvdJG by akapowl (@akapowl) on CodePen
 

Hello @Solbeg
 
 
What Mitchel said actually isn't 100% true - ScrollTrigger does have a built in porperty to match cases like yours, where you are pinning the parent element of your trigger element multiple times - it's the pinnedContainer property. This is from the ScrollTrigger docs:
 
pinnedContainer Element | String - If your ScrollTrigger's trigger/endTrigger element is INSIDE an element that gets pinned by another ScrollTrigger (pretty uncommon), that would cause the start/end positions to be thrown off by however long that pin lasts, so you can set the pinnedContainer to that parent/container element to have ScrollTrigger calculate those offsets accordingly. Again, this is very rarely needed. Important: nested pinning is not supported, so this feature is only for non-pinning ScrollTriggers (added in 3.7.0)  
That should fix your issue without a lot of custom code, but instead handled by ScrollTrigger internally (gotta thank GreenSock for that).
 
Does this work better for you?


See the Pen ExGEBpm by akapowl (@akapowl) on CodePen
 

Hello @Valuecom - welcome to the GSAP forum.
 
We actually like to keep the forum focussed on GSAP specific questions.
 
I personally am not aware of any helping library for handling iFrame loading states.

Since this isn't GSAP related, I just asked Google about this and here are some answers I got.

https://stackoverflow.com/questions/29233928/iframe-onload-javascript-event
https://stackoverflow.com/questions/3142837/capture-iframe-load-complete-event
https://stackoverflow.com/questions/60461930/checking-if-iframe-contents-are-loaded
 

Hello @Gourav Mukhija

You've already got a basis for what you plan on doing with the codepen example you provided.
 
In the demo it is animating horizontally from left to right because you have set it up like that. I'm not sure I understand exactly what it is you want, but if you want it to animate vertically instead of horizontally, you can just tweak the values neccessary for it to work that way.

Those are e.g. the rotation of the gradient from 90deg to 0deg and in your CSS as well as the JS the values for background-size and/or position to be appropriately set for it to work vertically instead - the first parameter of those always refers to the horizontal axis and the second to the vertical axis.
 
https://developer.mozilla.org/en-US/docs/Web/CSS/background-size
https://developer.mozilla.org/en-US/docs/Web/CSS/background-position
https://developer.mozilla.org/en-US/docs/Web/CSS/gradient/linear-gradient

I just tinkered about a bit and got it working like I imagine you'd want.
 
Hooking this up to ScrollTrigger the way you imagine, I'll leave up to you though. Good luck and happy tweening.
 
https://greensock.com/docs/v3/Plugins/ScrollTrigger


See the Pen PoXEgNz by akapowl (@akapowl) on CodePen
 

As far as I know, for performance reasons FLIP will only ever automatically target properties that are relevant for positioning of elements on the page.

If you want it to also tween on properties that might not be relevant for that - such as border-radii - you'll have to manually add them as props to the Flip.getState() method.
 
This is from the docs:

Flip only concerns itself with position, size, rotation, and skew. If you want your Flip animations to affect other CSS properties, you can define a configuration object with a comma-delimited list of props, like:
 
https://greensock.com/docs/v3/Plugins/Flip/
 
Does that work like you had in mind?


See the Pen dywZzEW by akapowl (@akapowl) on CodePen

Hi there @mhkey
 
 
That likely is because you never update the values that you only set once initially via your setHeight() function.

You could e.g. do so in a ScrollTrigger 'revert' eventListener. More on that in the docs.
 
https://greensock.com/docs/v3/Plugins/ScrollTrigger/static.addEventListener()
 

See the Pen rNowpwL by akapowl (@akapowl) on CodePen
 

Welcome to the GreenSock forums, @Wolfcoding
 
The actual source of your problem, is that you are pinning the parent-element of both the elements that you have ScrollTriggers on - thus they will both be inside the same pin-spacer element created by ScrollTrigger. The pin-spacer actually is the one thing that can make subsequent ScrollTriggers aware of prior pins - but if they both are in the same one though, that can't work as intended.

ScrollTrigger does have a built in property though to adapt to scenarions where pinning is done like you do - pinnedContainer
 
If you're going to pin that parent element of both those elements at some point  you will have to make sure to set that element in that property on any ScrollTriggers subsequent to the pinning one.

This is from the ScrollTrigger docs:
 
 
https://greensock.com/docs/v3/Plugins/ScrollTrigger
 
I hope this will help.


See the Pen PoXWLbd by akapowl (@akapowl) on CodePen