Jump to content
Search Community

ScrollSmoother, data-speed and first/last folds

Webit Interactive test
Moderator Tag

Recommended Posts

Hello,

 

I was wondering if there was a simple way to make it so elements are all lined up with a scrollTop of 0 and then have their different scroll adjusted upon scrolling? It seems that with ScrollTrigger animations and ScrollSmoother's data-speed, the offset calculated from its position in the viewport right away based on the start/end values despite where the scroll is located and therefore undesirable behaviour. I also believe this would create an issue with anything animated in the footer as the same logic would apply which is that elements will never be able to reach their "center" and therefore always be offset as opposed to arriving at their original state upon reaching the bottom of the page. (I'm aware that in most scenarios, the footer will not be animated in such a way, but I'm stating the two cases as only problematic examples.)

 

Expected behaviour:

Before: https://gyazo.com/658ec851f163d3382d96f9519bf26782

After: https://gyazo.com/699a0ae8a567f4aa08ccda0c150e933e

 

We've had our own version of a "data-speed" scroll and since we've been using GSAP for everything else, we want to shift over to ScrollSmoother since we believe there will be a gain in performance and will allow us better scoping  and usability of the animations.

 

Thank you

Link to comment
Share on other sites

It's pretty tough to troubleshoot without a minimal demo - the issue could be caused by CSS, markup, a third party library, your browser, an external script that's totally unrelated to GSAP, etc. Would you please provide a very simple CodePen or CodeSandbox that demonstrates the issue? 

 

Please don't include your whole project. Just some colored <div> elements and the GSAP code is best (avoid frameworks if possible). See if you can recreate the issue with as few dependancies as possible. If not, incrementally add code bit by bit until it breaks. Usually people solve their own issues during this process! If not, then at least we have a reduced test case which greatly increases your chances of getting a relevant answer.

 

Here's a starter CodePen that loads all the plugins. Just click "fork" at the bottom right and make your minimal demo

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

 

If you're using something like React/Next/Vue/Nuxt or some other framework, you may find StackBlitz easier to use. We have a series of collections with different templates for you to get started on these different frameworks: React/Next/Vue/Nuxt.

 

Once we see an isolated demo, we'll do our best to jump in and help with your GSAP-specific questions. 

Link to comment
Share on other sites

Hi @Webit Interactive. Thanks for being a Club GreenSock member! 🥳

 

I read your post a few times and I'm still very unclear on what you're asking, sorry.

 

On 3/17/2023 at 10:17 AM, Webit Interactive said:

It seems that with ScrollTrigger animations and ScrollSmoother's data-speed, the offset calculated from its position in the viewport right away based on the start/end values despite where the scroll is located and therefore undesirable behaviour.

What is this "undesirable behavior"? 

 

I'm sure once we see a minimal demo, it'll become much more clear. We'd love to help...just struggling to understand what you're asking. 

Link to comment
Share on other sites

Hello!

 

We can use the base codepen in the docs to use as an example:

See the Pen vYjrKWX by snorkltv (@snorkltv) on CodePen

As you can see, since the different data-speed offset is calculated based on the viewport (same with ScrollTrigger animations), the boxes are already offset even with a scrollTop of 0 instead of having their initial position on a scrollTop = 0 and then being animated on the scroll.

 

The behaviour that we wish to replicate without having to code exceptions would be similar to what we currently have which is that, even with different data-speed for each letter in a word, the word is still all lined up on a scrollTop =  and then would scroll at different speed rather than having proportional offset already being applied on the elements.

 

In my screenshots above, the first one is when we are at a scrollTop of 0, and the second one is when we start to scroll. As you can see, the letters have a different scroll speed, but they are still lined up together to form when at the top of the page.

 

Ref:

Before: https://gyazo.com/658ec851f163d3382d96f9519bf26782

After: https://gyazo.com/699a0ae8a567f4aa08ccda0c150e933e

Link to comment
Share on other sites

Hi,

 

I've read your posts in this thread a few times and I'm a bit fuzzy on what's the issue here.

 

In the codepen when the scroll position is 0 all letters are perfectly lined up, no issues there. You mention that at some point they are not lined up in your local setup when the scroll position is 0? That is not reflected in the codepen so unfortunately we can't debug anything there.

 

If this is happening on our local setup, be sure to use the same versions of the GSAP core, ScrollTrigger and ScrollSmoother. The current version is 3.11.5. Besides that I'm afraid there is not a lot more I can do for you.

 

Another alternative is start with your codepen example on your local environment and start adding other sections and scripts until it breaks, then you'll be able to isolate what is causing this.

 

Hopefully this helps.

Happy Tweening!

Link to comment
Share on other sites

9 hours ago, GreenSock said:

Are you trying to do something like this?: 

 

 

 

 

That is exactly what I wish to have as default behaviour!


I'm guessing by the added JS code to manipulate the data-speed that there is no current way to have it this way as a default behaviour for ScrollTrigger / Data-speed animations without having to loop through the animations and manipulate the start values?

Link to comment
Share on other sites

@Webit Interactive I'm exploring the possibility of making this an optional behavior that you could trigger by perhaps adding a "+=" prefix to your data-speed: 

<div data-speed="+=0.5"></div>

The "+=" prefix basically does everything exactly the same EXCEPT if the element starts out in the viewport (meaning the effect's ScrollTrigger would have a negative "start" value), it'll make all the necessary adjustments to keep it in the natural position initially. It does seem useful. 

 

I dropped that into the latest beta file that works on CodePen/CodeSandbox/Stackblitz: 

https://assets.codepen.io/16327/ScrollSmoother.min.js

 

(you'll probably need to clear your cache)

 

Is that what you're looking for? I can't guarantee this feature will end up in an official release, but I wanted to tinker with it and invite input/suggestions (including the API, like the prefix or suffix we'd use on the value or whatever). Let me know what you think. 

 

See the Pen gOdqwKr?editors=1010 by GreenSock (@GreenSock) on CodePen

Link to comment
Share on other sites

@GreenSock

That is exactly what we are looking for and I'm sure people would benefit from this behavior for their banner animations! Having to simply add "+=" to the value makes it simple and easy for usage.

 

However, I'm wondering if that would work for a situation like a footer where the element should reach its initial state when we reach the bottom of page? Perhaps using "-=0.5" for that situation could work? As it is the same logic, except backwards.


Also, if there was an option we could pass to ScrollTrigger as well to have the same behaviour for those scrub animations, that would be the icing on the cake! For example, if we add a 1.5 zoom scrub effect on the backround-image of our banner, it would already start with a 1.XX zoom value since it's completely in the viewport with a scrollTop of zero. Do you think that is something that would be possible?

 

Link to comment
Share on other sites

8 hours ago, Webit Interactive said:

However, I'm wondering if that would work for a situation like a footer where the element should reach its initial state when we reach the bottom of page? Perhaps using "-=0.5" for that situation could work? As it is the same logic, except backwards.

It's not quite that simple, but I spent most of today working on that feature and I believe I've got it working in the beta: 

https://assets.codepen.io/16327/ScrollSmoother.min.js (probably need to clear your cache)

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

 

8 hours ago, Webit Interactive said:

Also, if there was an option we could pass to ScrollTrigger as well to have the same behaviour for those scrub animations, that would be the icing on the cake! For example, if we add a 1.5 zoom scrub effect on the backround-image of our banner, it would already start with a 1.XX zoom value since it's completely in the viewport with a scrollTop of zero. Do you think that is something that would be possible?

I don't quite understand - can you please provide a minimal demo that clearly shows the challenge you're facing and describe what would be different than the current behavior? 

Link to comment
Share on other sites

  • 2 weeks later...

@GreenSock

 

Amazing work on the footer data-speed functionality! That is the behavior we are looking for :)

 

I've re-used your codepen for an easy example of the logic on ScrollTrigger.

As you can see on the first fold, the same logic applies for the animation that is already partially completed on a scrollTop of 0. When we get to the top of the page (or load initially), the scale animation is already at ~1.335 for a 1.5 scale animation.
Ideally, we would be able to apply the same logic where the animation is at a progress of 0 (0%) when we are at the top of the page and progress to 1 (100%) upon scrolling.

 

See the Pen jOeONdb by mpare (@mpare) on CodePen

Link to comment
Share on other sites

Alright, I've been rethinking this API. Instead of "+=" and "-=" prefixes on the speed and then having some other way of handling the scaling animations as you described, @Webit Interactive, I think it'd be cleaner and more intuitive to use a "clamp()" wrapper across the board which basically means "don't let the ScrollTrigger's start position be LESS THAN 0, nor the end position GREATER THAN the page's maximum scroll"

 

// you can put any valid start/end value inside the clamp()
start: "clamp(top bottom)",
end: "clamp(bottom top)"

And then for data-speed: 

data-speed="clamp(0.5)"

So here's a forked CodePen of the original with clamp() in place with beta files:

See the Pen BaqzJrM?editors=1010 by GreenSock (@GreenSock) on CodePen

 

And here's a fork of your scale demo with clamp() in place:

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

 

This way, we've got a consistent way to tell ScrollTrigger to limit the start/end of the associated ScrollTriggers. 

 

Thoughts? Suggestions? @andrius.petravicius I'd love to hear your thoughts too. Please feel free to hammer on those beta files to see if you can get any odd behavior. Also feel free to suggest a different API design for this kind of feature. 

Link to comment
Share on other sites

@GreenSock

There does not seem a way to put it so that it actually scrolls up rather than down as shown in the initial use case here:

Using "clamp(0.5)" versus "clamp(-0.5)" versus "clamp(1.5)" versus "clamp(-1.5)" you can compare the issue in your forked codepen.

See the Pen XWYKOMM by mpare (@mpare) on CodePen

 

I also feel like there must be something with the calculations for the translating. I may have things backwards for the way ScrollSmoother uses it for its logic, but shouldn't a positive data-speed like "2" make the element go up faster rather than down faster? Since we are scrolling down, an element with a higher data-speed should behave as though every pixel scrolled down increases it's speed going out from the top and a value below 1 should mean that it scrolls slower than than a normal item and therefore stays in the viewport longer.

However, the logic can also be reversed and used as the way it is at the moment, but should allow for elements to also scroll up faster rather than scrolling down.

Link to comment
Share on other sites

  • 2 weeks later...
  • 1 month later...

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 account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...