Feature suggestion for ignoreMobileResize of ScrollTrigger

[benrbnt]

Hello !

 

I was thinking of a modification in the implementation of ignoreMobileResize. It is a pretty cool feature that I like to use for many animations controlled by ScrollTrigger. I think it is mainly used to avoid safari "issue" when having the navigation appearing / disappearing. And it avoid having "jumps" on scrubbed animations. But for triggered animations ("actions") I often do not need to have this option enabled (cause it calls the leave (back) of a ST, even if it is still in the viewport). So I was wondering if it could be possible to have it more as a ScrollTrigger instance option instead of a global config ?

[Rodrigo]

Hi,

 

Currently you can use the normalizeScroll method to prevent the hide/show behaviour on mobile devices:

https://greensock.com/docs/v3/Plugins/ScrollTrigger/static.normalizeScroll()

 

As for making the ignoreMobileResize config something that works on specific ScrollTrigger instances is kind of hard you know. The resize of the browser window is a global thing, not something that happens just for a few instances in a page, it affects the entire layout. Also that would force GSAP to start looking for every single ScrollTrigger instance and make it work differently depending on it's own config which could bring a performance issue. You can turn it on/off on specific pages without any major hassle and you can also detect specific devices as well.

 

Still I'll ping @GreenSock so He can give us a more definitive answer on the subject.

 

Happy Tweening!

[GreenSock]

No, I don't think that's very feasible because it's sorta like saying "refresh(), but only a certain subset of ScrollTriggers" but in order for things to be accurate, everything must be refreshed from the top down (in order) because some things further down the page are affected by ScrollTriggers higher up. Like if a section is pinning, that adds pinSpacing which pushes other things down, affecting their start/end positions. If we start doing only a subset of the ScrollTriggers in a refresh, that seems like it could cause things to get inaccurate in a cascading way. 

 

I suppose you could argue that's okay if it's opt-in anyway and I guess I'd agree but I'm just not sure it's worth the extra kb and complexity to implement this kind of thing. Perhaps if others request it, that would evidence the need for it. We just have to be careful about adding features that only 0.001% of users would ever tap into (because it forces everyone to pay the kb/complexity price). See what I mean? 

 

If this is a critical feature for your particular project and you'd like to hire us on a consulting basis to solve it for you, feel free to reach out to us and we can discuss it. 

[benrbnt]

@Rodrigo The normalizeScroll() of GSAP is a bit unstable on iOS, might need to go on alternatives like Locomotive Scroll (but the goal is to avoid that)

 

@GreenSock Well seen, didn't thought about this issue...

The fact is that if using ignoreMobileResize and having a scrubbing ScrollTrigger at bottom of the page (end of the scroll) with something like {end: 'bottom bottom'} -> The end of the trigger will never reach the end of the scroller. A simple reproduction of the issue: 

See the Pen YzvLEvJ by benjaminrobinet (@benjaminrobinet) on CodePen

 (as Codepen uses an Iframe,  the ignoreMobileResize won't be very useful here, but you got the idea. It is like having 'bottom 75%'). Do you have any idea on how to handle that ?

[Rodrigo]

Hi,

 

Yep, the fact here is that the URL Address bar is being show/hide as you scroll up/down and ScrollTrigger is not refreshing because the threshold for that is not being passed as stated in the ignoreMobileResize docs:

 

ignoreMobileResize if true, vertical resizes (of 25% of the viewport height) on touch-only devices won't trigger a ScrollTrigger.refresh(), avoiding the jumps that can happen when the start/end values are recalculated. Beware that if you skip the refresh(), the start/end trigger positions may be inaccurate but in many scenarios that's preferable to the visual jumps that occur due to the new start/end positions.

 

In that case you should try the normalizeScroll method:

ScrollTrigger.normalizeScroll(true);

Here is a live example:

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

 

You can open it directly in debug mode (no iframes) on your device with this link:

https://cdpn.io/pen/debug/BaVxqbP

 

Hopefully this helps. Let us know if you have more questions.

 

Happy Tweening!

[GreenSock]

Yep, like Rodrigo said, this is a fundamental logic issue. You cannot have your cake and eat it too

 

If the address bar shows/hides, that changes the height of the viewport which of course affects anything with "vh" units (very common). So let's say you've got 10 sections that are each 100vh tall. If the address bar then shows and the viewport gets 50px shorter, for example, that means your overall height of all the content just shrunk by 500px! So if we skip the ScrollTrigger.refresh(), all the start/end values stay the same, thus you'll never be able to scroll down far enough to hit any of the ScrollTriggers that had their start in the last 500px. But if you do ScrollTrigger.refresh(), of course it corrects all the start/end values but that could cause things to "jump". Perhaps you were halfway through a scrubbed ScrollTrigger animation before the resize, but now with everything recalculated it puts the scroll position at 70% through that animation (thus it'd jump from 50% to 70% progress). 

 

There's no magical way to say "adjust all the start/end values to be accurate AND ALSO don't allow any jump". It's logically impossible. 

 

The normalizeScroll() feature attempts to solve this by preventing the show/hide behavior of the address bar but that's not always possible, like on iOS mobile phones in the latest version of iOS, it FORCES the show/hide. Super annoying - it's actually an iOS bug but there's no indication that Apple will fix it. So we've really done our best to give you the tools to choose which tradeoffs are best in your particular scenario. I really wish we had a silver bullet.