celli

Thanks for the insights. Adding the borderRadius to the timeline will not help. Since you added 2px it might not be as noticeable as 8px, but it doesn't really solve the issue. I think to Rodrigo's point I will just animate the width/height since performance-wise the shadow will be doing more work than the width/height calculations. I was hoping there was something I was missing that could accomplish this while keeping the border radius intact, but I see the issue and no silver bullet. Thanks again guys.

I understand that animating the 'width' or 'height' properties are not performant or recommended vs. using scaleX and scaleY, so I am trying to use scale. The only issue is that while using scale, since my scaling of X and Y s not equal, my border-radius is effected and creates a strange shape. Is there anyway around this, or would it be okay to just animate the 'width' and 'height' in instances like this?

Hi Cassie, Yes awesome. Very nice, thank you.

Hi Jack, You were absolutely correct. I had something else in my project that was causing the issue. I am also animating the elements on window load, and this is what was causing the issue. I updated the codePen with this intro animation. If I mouseenter quickly on the element (before the initial window.load animation ends) then I would run into the issue. I wrapped a setTimeout function (or I could use a callback) on my functions that control the hover effects and that did the trick—but is there a better way using GSAP to accomplish this?

Hi, I have a gsap timeline that seems to stop mid way through the animation when I mouseleave quickly. The point at which it stops seems to be unpredictable in my real project, but it's always when I move my mouse quickly. It doesn't seem to happen much on this codePen, but it does happen pretty often in my project. I tried to set the progress back to 1 and then kill it (as you see in my codePen) but it still doesn't seem to work effectively. I still want it to animate in reverse on mouseleave, but in-case it gets stuck I'd like a way to force it back to the starting position.

This is great PointC and Jack, thank you!

Hi all, I hate to dig this one back up. As I dug deeper into it, I noticed that it seemed to kill all of my scrollSmoothers, not just the ones that I am trying to target. For instance I added two boxes above the images without the class of .smootherReset768 and while those keep their original data-speed attributes (resizing below 768px), the smoothScroller stops working for those elements as well. When I resize the browser to above 768px only the elements with my class .smootherReset768 re-initiate the scrollSmoother behavior. I tried it several different ways, but I was still not able to get my other elements without the target class of .smootherReset768 to retain the scrollSmoother behavior, without removing the t.kill() function.

*** EDIT: Sorry, it does work, I had to add OSUBlake's t.kill() -- I forgot about that ***

I actually notice now that I test my codePen further in live mode, when I resize my browser multiple times, the behavior doesn't seem to stick, the original values seem to remain persistent. I also notice that if I start my browser under 768px wide, the data-speed change doesn't take effect.

thank you guys, this works nicely. And it will work selectively (only for the elements that I'd like it to effect) perfect.

yes, exactly. I tried this with the loop in my else statement, but I must be doing something incorrectly. I just don't see how I am recording my originalSpeeds. If this is beyond GSAP support I totally understand, I will keep trying on my own and appreciate the help.

I'd like to set effects to false, but only for elements with a certain class of .smootherReset768, and then set them back to their original, so I really don't want to kill the whole scrollSmoother. When I try to recreate the scrollSmoother in my resize function it doesn't seem to work, so I f figured if I can capture the original values and then re-inject them into the elements when I resize over 768px that would work (also as you suggested), I just wasn't able to get that working. I see your code above so I'll give that a whirl, but it doesn't reference the elements with the class of .smootherReset768, so I'm not sure where I get the originalSpeeds from.

I am trying to create the loop, record values and then return them back into my elements, which I have not been able to do successfully as you can see in my pen—but now I am wondering can I kill() the existing scrollSmoother in the elements with this class only, and then restart scrollSmoother in my resize function? Or would that not work?

humm, yes that will be the trick I will try

Hi, I have a scrollSmoother page setup and I am using in-line data-speed attributes. I am changing the data-speed at a 768px break-point, because *some* of my content stacks at that break point and I need to change the data-speed at that break-point, which works well. I want to return my data-speed to their original settings when my browser resizes again to larger than 768px, is there a best way to accomplish this? Obviously I do not have anything in my else statement to change the data-speed to anything specific, but since there will be many elements that will use this technique (and the data-speed numbers would be different for each, depending on what the situation is), I want to see if I can easily return each of the elements to their original data-speed in some way that I might be missing or with smoothScroller ? If you resize my codePen, look at the 2-column images and then resize back to above 768px, you will see what I mean.