Jump to content
GreenSock

Search In
  • More options...
Find results that contain...
Find results in...
celli

scrollTrigger matchMedia

Recommended Posts

When using matchMedia with scrollTrigger, it works well when I start my page at < 800px and then when resizing my browser window to > 800px (just as an example).

 

But it seems that when I resize back to less than 800px, the position of my element does not return to it's original y value (it remains far down the page). I am guessing I need to add something else to completely kill the scrollTrigger values and reset my element to it's original css positioning. What is the best way to accomplish this ? My CodePen example  should illustrate what I mean.

See the Pen PoZrxey by celli (@celli) on CodePen

  • Thanks 1
Link to post
Share on other sites

Hey celli. You can fix this in your case by setting immediateRender: false. However, if your start position was any point after the bottom of the viewport that wouldn't work. It's likely an edge case that we need to handle better.

  • Like 1
Link to post
Share on other sites

yep, that works!

 

Can I get the scrollTrigger to start below the bottom of the viewport? How can I set that up? Actually I was trying to do that (in some cases) because some elements that reside close to the top of the page (like this one) - I was hoping to limit the amount of scrolling before getting to the first element that animates with scroll. This was the reason I wanted to disable it on smaller monitors, since the element would appear too low in the viewport.

Link to post
Share on other sites

Sure, just change your start and/or end positions. 

start: "top 120%",

 

  • Like 1
Link to post
Share on other sites

right, of course! not sure why I thought we could only go to 100%. That is great!

 

It still seems to work with immediateRender:false; I updated my codePen to reflect this, and still seems to work ...

Link to post
Share on other sites
3 hours ago, celli said:

It still seems to work with immediateRender:false; I updated my codePen to reflect this, and still seems to work ...

Indeed it does. I meant a value like start: "top center" wouldn't work currently because it'd still have the offset on mobile sizes.

Link to post
Share on other sites

Short answer: 

Save the initial styles so that they can be reverted cleanly: 

ScrollTrigger.saveStyles(".scrollFadeUp");

(Do that BEFORE your ScrollTrigger.matchMedia() call)

 

Longer explanation:

A from() tween will of course jump to the provided values immediately and record those internally as the start. When ScrollTrigger does its teardown to revert values, it attempts to rewind that tween...but that would mean applying the starting values which in this case has yPercent: 50. What immediateRender: false does is tell GSAP "hey, these values should only jump there at the very start, so make sure you record the INITIAL values too so that you can revert those later". 

 

It may help to think in terms of a timeline. Let's say an element's opacity is at 1 (natively) and then 2 seconds into a timeline we insert a from(... {opacity: 0}). When that timeline starts, what would you expect the opacity to be at? In most cases, people would expect it to remain 0 for 2 seconds and then animate up to 1. In other words, when the timeline's playhead went BEFORE the tween's start, it didn't say "oh, revert opacity to the initial value of 1"...it just let it be 0 from the immediateRender. There was no need for the from() to record (or apply) the initial state because immediateRender was true. But if you set immediateRender to false, opacity will stay 1 for the first two seconds of that timeline and then BOOM, it jumps to zero and fades up. When immediateRender is false, it signals to the from() tween to record the initial state and apply it whenever the playhead goes backward before a time of 0. 

 

So when ScrollTrigger rewinds that playhead in your scenario, it doesn't apply the initial values since immediateRender was true by default. 

 

It's doing exactly what it's supposed to do. 

 

So setting immediateRender: false is indeed a viable solution here, but I personally favor ScrollTrigger.saveStyles() because it's even cleaner (it removes any inline styles that were added by tweens). 

 

Does that clear things up? 

 

From what I can tell, this is NOT a bug, but let me know if you feel otherwise. 

  • Like 3
Link to post
Share on other sites

perfect explanation, thanks!

  • Like 1
Link to post
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.

×