Jump to content
GreenSock

Shehzad Asif

ScrollTrigger does not revert elements to their original values on resize

Go to solution Solved by GreenSock,

Recommended Posts

Hi There

 

I am observing that scrolltrigger based animation does not revert to their original values on window resize. For example, my animations are for only desktop size devices (e.g " from ypercent 100, opacity: 0), using ST matchmedia function for this purpose. On first load everything works fine but as you resize the window, animation based elements disappeared (elements go back to "ypercent 100, opaity 0) on non-desktop devices while they should be at "ypercent 0, opacity 1". That can be seen in attached demo. 

 

I used the following code for tracing ST progress from a post but does not seems to help instead it takes the window to top each time on window resize.

// code for tracing scrolltrigger progress in check
const ST = ScrollTrigger.create({
  trigger: "body",
  scroller: "[data-scroll-container]",
  start: 0,
  end: "bottom bottom"
});
// The relevant part to keeping the progress
ScrollTrigger.addEventListener("refreshInit", () => (progress = ST.progress));
ScrollTrigger.addEventListener("refresh", () =>
  ST.scroll(progress * ScrollTrigger.maxScroll(window))
);

 

How this thing can be avoided so that they remain in their original position on resize on all devices.

 

Regards

Shehzad Asif

See the Pen ExWxBrM?editors=1010 by ShehzadAsif (@ShehzadAsif) on CodePen

  • Like 1
Link to comment
Share on other sites

I'm hanging on @akapowl's response here because I dug into the ScrollTrigger docs and could only figure out how to do this with

ScrollTrigger.saveStyles(".imgs-container img");

to save the initial values, *but* this only seems to work if the images are animating in below the bottom of the viewPort - otherwise the images on desktop start at their native state, then flick to their 'from' autoAlpha:0 state...

See the Pen 58209bc664a903b78b263f95a241af80?editors=1010 by cassie-codes (@cassie-codes) on CodePen



intrigued. Definitely gonna learn something here...

  • Like 1
Link to comment
Share on other sites

I found this forum post from Jack that looks related - 

 

  • Like 1
Link to comment
Share on other sites

 

I am not the most confident with ScrollTrigger's .matchMedia yet, but setting up media-queries in your CSS alongside using ScrollTrigger.saveStyles() makes it work properly for me.

 

Could that be an option for you?

 

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

 

 

 

On a sidenote:

You should probably set your [data-scroll-container] to overflow-hidden. If e.g.  you have a heading with a margin-top set on top of your page like that, it will push down your [data-scroll-container] which could at least lead to problems with your layout later on. 

 

 

 

I noticed some quirky behaviour on resizes with .matchMedia() and locomotive-scroll here (tried with smooth-scrollbar, too, and it's similar there, so I guess it's a smooth-scrolling thing) - not sure if it's due to some faulty setup with the .scrollerProxy in combination with .matchMedia() here, or something else, though.

 

If there are only ScrollTriggers being created for one matching media-query like in this example - ScrollTriggers only for 1025px and above but nowhere else - the following happens. When you start out on a width that has ScrollTriggers and scroll down, then change the browser to a size where there are no ScrollTriggers set for and scroll up again - then, when you resize the brwoser back to a size where there are ScrollTriggers, the page will automatically scroll down to that last point it was at when you left the page on the size with ScrollTriggers defined.

 

Well, since that sounds very complicated, here is a screen-recording

 

 

 

As soon as you add any ScrollTrigger to the  'all'-query, that behaviour goes away - even if it's just something like

 


... 

all: function () {

  ScrollTrigger.create({
    trigger: '.imgs-container',
    scroller: "[data-scroll-container]"
  })

}

 

 

So I am very likely missing something here.

Hope @GreenSock could shed some light on this.

 

 

  • Like 1
Link to comment
Share on other sites

Hey all,

 

Thanks for your advice and suggestions and this is one of the reasons I love this forum. People are always ready to help each other.

I just made a minimal demo to show the problem. It looks like an applicable solution what pawl mentioned for few animation or tweens but not for bigger picture where you have a website have like 3 to 5 pages and on each page you have like more or less of 50 tweens or animation mix of text and images or some other stuff and sometime complex timelines for different breakpoints. Doing CSS work for each element in this way is like doubling or tripling your work and may be impossible in some cases where you are setting the things only with JavaScript or dynamically. 

 

@akapowl I forked your demo and commented out "all: function" media query. It is causing the scroll effect on resize as in my demo. Now that window scroll effect is gone. But I am just thinking, Is it the most efficient way to revert to original position of elements 😒.

 

See the Pen YzZPEEo by ShehzadAsif (@ShehzadAsif) on CodePen

 

@Cassie Thanks for sharing the post. I already tested the "immediate Render: false, save Styles" both comes with the same result like you mentioned. The elements will remain at their initial state until they are triggered. Below is the demo with "immediate Render: false".

 

See the Pen BaWyrXW by ShehzadAsif (@ShehzadAsif) on CodePen

 

Let's see what Greensock says on how to tackle this.

 

Regards,

Shehzad Asif

 

 

Link to comment
Share on other sites

  • Solution

Yep, I actually patched that saveStyles() issue a few weeks ago, so it's in the latest beta: https://assets.codepen.io/16327/ScrollTrigger.min.js

 

Here's a fork:

See the Pen abJzKxV?editors=0010 by GreenSock (@GreenSock) on CodePen

 

Does that work more the way you expected? 

 

Note that I also told LocomotiveScroll not to smooth-scroll to the proxy setter value:

locoScroll.scrollTo(value, {disableLerp: true, duration: 0})

 

And @akapowl, I didn't notice the resizing issue that you described (in the latest beta) - do you? I didn't do anything in particular to "fix" it, but perhaps it was related to something else that was already patched, or it was related to the logic that @Shehzad had in there that was adjusting the scroll on refresh (which I removed in my fork). 

  • Like 1
  • Thanks 1
  • Haha 1
Link to comment
Share on other sites

Hey Jack

 

Awesome, Now the behavior is as expected. You guys are awesome every time. I would like to have 2 questions as add on.

 

1- When this beta can be used/ released officially so I can use in my project.

2- Is it possible that irrespective of the breakpoint once the tween is played ,it does not play later on each time I resize. I used "once: true" has no effect (tried although it was not going to work in this way as per documentation). The tween plays each time I resize from 1025px breakpoint to back and forward.

 

And yes, Thanks for the amazing support.

 

Regards,

Shehzad Asif

Link to comment
Share on other sites

21 minutes ago, Shehzad said:

1- When this beta can be used/ released officially so I can use in my project.

I can't say for sure (still working on a few ideas), but you're welcome to use the beta file. 

 

22 minutes ago, Shehzad said:

2- Is it possible that irrespective of the breakpoint once the tween is played ,it does not play later on each time I resize. I used "once: true" has no effect

Not without wiring up some conditional logic on your own. Those breakpoints (media matches) are triggered whenever they match, so it's not like ScrollTrigger says "the user already hit that breakpoint, so ignore it from now on". You'd need to use some flags of your own. 

  • Like 2
Link to comment
Share on other sites

This was a really enlightening thread. Love it. 🙌

Thanks Jack

  • Like 3
Link to comment
Share on other sites

12 hours ago, GreenSock said:

And @akapowl, I didn't notice the resizing issue that you described (in the latest beta) - do you?

 

Unfortunately it's still there for me - with the lerp disabled in the scrollerProxy now it will not scroll to that previous position but instantly jump there.

 

There is still that one ScrollTrigger being created outside of the .matchMedia() function in your fork. Since it will be active on all sizes you wouldn't notice the behaviour I mentioned.

 

const ST = ScrollTrigger.create({
  trigger: "body",
  scroller: "[data-scroll-container]",
  start: 0,
  end: "bottom bottom"
});

 

 

You should notice though, when you remove that ScrollTrigger and there are only ScrollTriggers for above 1025px in the matchMedia function.

 

See the Pen 1f1ead8fcb7ff737c95f3073cfa36ecd by akapowl (@akapowl) on CodePen

 

  • Thanks 1
Link to comment
Share on other sites

@akapowl 

Quote

I forked your demo and commented out "all: function" media query. It is causing the scroll effect on resize as in my/ your demo. Now that window scroll effect is gone.

See the Pen YzZPEEo by ShehzadAsif (@ShehzadAsif) on CodePen

 

It is quite weird, I do not see that resize issue again in your codepen either after commenting out "all" media query. 

Link to comment
Share on other sites

 

Thank you @Shehzad, I've tried that before - and the pen in my latest reply doesn't have a query for all but I can still reproduce it.

 

Tested on latest Chrome and FF (Win 10) on codepen (debug view of course) and locally.

Link to comment
Share on other sites

@akapowl Now I tested it repeatedly like continuously for 30 to 50 times back and forth resizing then I am able to see it for 2 times that jumping issue (quite hard to reproduce "probability of 2 from 30/50") but yes that effect is there.

 

I just implemented the latest beta in my project on localhost (now that value revert issue is gone), and I can confirm that powl is right on resize content does not remain on previous position some time, it jumps/ scrolls to some other position.

Link to comment
Share on other sites

I'm trying to debug responsive issues I'm having and think my issue might be related.  I've been trying everything I can to debug and with my usage I just can't get ST to recalculate position the same way it does when it loads.  At one point it was hiding elements with my 'from' values I think, also, but if you resize this pen small and back it hides everything.  If this isn't related, don't mean to hijack, just trying to help get to the bottom of this.  

See the Pen QWdrYjO?editors=0111 by davidbwaters (@davidbwaters) on CodePen



Just for reference, here's the landing I'm trying to use it on (it's at the bottom), which has a lot of other stuff going on that is probably effecting it, but the behavior may help debug.  I managed to tweak to where it behaves oddly here and stays visible, but isn't getting the position in the same way it does when it loads.  i tried setting a timeout to make sure anything else resizing with just is done, which i had to do on load for it to work right.  https://upbeat-hugle-f33533.netlify.app/

Link to comment
Share on other sites

16 hours ago, akapowl said:

There is still that one ScrollTrigger being created outside of the .matchMedia() function in your fork. Since it will be active on all sizes you wouldn't notice the behavior I mentioned.

Ah, got it. Should be resolved in the latest beta: https://assets.codepen.io/16327/ScrollTrigger.min.js

 

@davidbwaters your demo did expose an edge case related to SVG elements and the fact that their transforms are recorded in the "transform" property, not the cssText, so I needed to tweak the ScrollTrigger.saveStyles() functionality accordingly. It should be resolved in the latest beta (linked above). Thanks for bringing this to our attention and for taking the time to provide a minimal demo. Very helpful indeed. 

  • Like 2
  • Thanks 1
Link to comment
Share on other sites

Hi Jack

 

I used the above beta. Resize issue is there when rotating the device (test locally on chrome dev tools).

Link to comment
Share on other sites

6 hours ago, GreenSock said:

Ah, got it. Should be resolved in the latest beta

 

Yes, looks (to me) like you did!

On my end the automatic jumping/scrolling doesn't happen anymore 👍

 

 

3 hours ago, Shehzad said:

I used the above beta. Resize issue is there when rotating the device (test locally on chrome dev tools).

 

I tested this in a normal page view on desktop, in dev tools rotating the 'device' and on mobile (Samsung Internet - Android 11) and for me the mentioned resize issue doesn't appear in any of those anymore. Maybe you just need to clear your cache for the beta to be used @Shehzad

 

 

  • Like 1
Link to comment
Share on other sites

On codepen I don't see that issue, that's right. Actually I tested it on my project on localhost so may be some other code causing it, not sure. Will check and test again.

 

One thing is that I observed that issue on a device that have both breakpoints like ipad pro, (portriat width: 1024px. landscape width: 1366px). If a device that have these both breakpoints then that issue appears to me. Other then that do not observe that issue. Just a point.

Link to comment
Share on other sites

7 minutes ago, Shehzad said:

On codepen I don't see that issue, that's right. Actually I tested it on my project on localhost so may be some other code causing it, not sure. Will check and test again.

Sounds like maybe you weren't using the latest beta file that I linked to above? Or maybe you didn't clear your cache? 

 

8 minutes ago, Shehzad said:

One thing is that I observed that issue on a device that have both breakpoints like ipad pro, (portriat width: 1024px. landscape width: 1366px). If a device that have these both breakpoints then that issue appears to me. Other then that do not observe that issue. Just a point.

I didn't understand this comment. Can you explain exactly how to reproduce the issue and what the precise issue is that you're seeing? Do you have a minimal demo? Or are you saying that the demo from @davidbwaters breaks only on an iPad Pro, and you're positive you're using the latest beta file too but it still occurs? That sounds very odd to me. 

Link to comment
Share on other sites

1 -It is not related to david issue.

2- I was using chrome in incognito mode so no cache, with latest beta.

3- I found the issue, the displacement is causing due to margin of an element on desktop. I made a minimal demo for understanding. when you switch from desktop to 1024px, you will notice that window will scroll to last image instead of img-3 as it has 200vh margin on desktop and none at below 1025px. if you switch back to desktop it will go back to img-3.

See the Pen ExWjmbg?editors=0110 by ShehzadAsif (@ShehzadAsif) on CodePen

 

Regards,

Shehzad Asif

 

Link to comment
Share on other sites

Ok, I made a scenario that is quite similar to my situation. Here you can see that I have a pin img at desktop nothing at below 1024px. Same as above If I switch between these breakpoints you can see the content shifting that is due to that pinSpacing. 

See the Pen KKWpyBW?editors=0110 by ShehzadAsif (@ShehzadAsif) on CodePen

Link to comment
Share on other sites

Hm, perhaps I'm missing something here but what exactly did you expect to happen if you're removing the pinning and you've scrolled down on the page further than the pin? Like...let's say the window is scrolled to a position of 8000px but when you resize the window and the matchMedia() kills the scrollTrigger so that the page is significantly shorter, how are you expecting it to recover from that? I'm not at all surprised that there would be a jump in that scenario because the content just got a lot shorter. See what I mean? Or maybe I'm missing something else that should be obvious. 

  • Like 2
Link to comment
Share on other sites

It's also maybe worth pointing out that as Developers - we resize our screens a lot to debug and test websites.

If you're a bit of a perfectionist, like a lot of us are - you can get a bit hyper-focused and hung up on what the transitionary states look like. I know I have in the past. But, in my opinion, it's unnecessary. Non-devs don't resize browsers and pay attention to what the layout is doing in between states. 

Content shifts happen when you resize a browser. It's not a bad thing!

  • Like 2
Link to comment
Share on other sites

Jack I got it, it's an expected behavior in that scenario. Thanks for clarification.

 

Quote

you can get a bit hyper-focused and hung up on what the transitionary states look like.

 @Cassie I agree as I used to focus on very tiny tiny details that nobody worries in the real world. I am overdoing it sometime. Thanks.

 

I am sorry that question is not related to gsap but as an opportunity I would like to ask what platform you guys recommend for cross browser testing like lambda or what.

  • Like 2
Link to comment
Share on other sites

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.
×