Why does Scrolltrigger adds overflow-y to the body?

[xoxoxoxo]

I have a page with position absolute panels. I see Scrolltrigger adds overflow-y on body as an inline style. Why?

Also, the overflow-y doesn't get removed if I navigate to a different page.

Shouldn't killing the Scrolltrigger instance remove the inline style? I do kill all the instances when navigating to a new page.

[akapowl]

Hey @nullhook

 

What makes youthink this is applied by ScrollTrigger?

Could you please provide some more information and maybe a demo that shows this happen?

 

I ask, because I don't see this happen in any of my own builds with ScrollTrigger.

 

[xoxoxoxo]

Looking at Scroltrigger's source, here's the line where it happens.

Apparently if the body doesn't have scroll on initial paint...this adds it? Correct me if i'm wrong though.

However, if I kill the instance of the Scrolltrigger shouldn't the overflow from body be removed? 

[GreenSock]

Yep, that addresses a very rare edge case and it's necessary to ensure proper sizing. As for removing that if you kill the ScrollTrigger, I'm not sure it's worth all the extra kb to juggle that because remember that there can be MANY ScrollTriggers on a single scroller, so in order to do what you're asking:

1. Upon instantiation, each one would have to check the computed value, if it's not set to "scroll" it would need to add that inline and record that it did so.
2. Then when disabled/killed, each one would have to check with all the other ScrollTriggers and say "hey, are you cool with me removing this? Are you still using it?"

The alternative is for you (or any user who runs into this very rare edge case) to just set overflow to whatever you want after you kill(). See what I mean? Is there some reason you don't want to do that? 

[akapowl]

On 11/27/2020 at 7:12 PM, GreenSock said:

The alternative is for you (or any user who runs into this very rare edge case) to just set overflow to whatever you want after you kill(). See what I mean? Is there some reason you don't want to do that? 

 

As I was just in the process of answering, here's a demo

 

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

[xoxoxoxo]

@GreenSock Makes sense.

I'd like to know why adding an overflow y ensures proper calculation? Is this only on pages that had divs absolutely positioned?

[GreenSock]

The explanation was in the raw source code you linked to. 

 

No, it's not just for absolutely positioned things. Imagine a page where you're doing pinning which adds padding (pinSpacing), but the initial state of the page has NO scrollbar (the content is short). If calculations for width/height, etc. are done in that state, it won't include the space that the scrollbar takes up. Like if the window is 1000px wide and you've got elements that are width: 100%, they'd be 1000px of course. Then, when the padding is added and things grow taller, the browser adds a scrollbar which might be 16px (it's different based on operating system and browser), thus the width of those elements would be 986px. See the issue? 

 

If the pinSpacer element is 1000px (based on the state without overflow-y: scroll), suddenly you've got a horizontal scrollbar introduced that's not necessary. 

[PurpleAsia]

You can add "overflow-y:auto!important" in css with body

[Silverback IS]

Is it necessary to add this style if pin spacers are turned off? It does create some issues listening to window scroll events.

 

So on a mobile app using VueJS or something, if you load a page which has no scrolling, then switch to a page which does, then scroll trigger plugin wouldn't work. Basically I have built this https://www.ambertutton.co.uk/

 

The background you see on the text pages (contact and about) is pinned always and part of the layout. So on mobile devices it is always 100% viewport height and visible. If I load the contact page first, it usually will not scroll on a user's screen. So the style is added to the body. But then I switch to a gallery page, and no gallery images will animate in because we listen for window scroll events which no longer fire.. my nav bar is also listening for window scroll events which no longer fire.

 

Interesting...

 

I have just set the body overflow to visible and forced it with !important for now.

[GreenSock]

@Silverback IS it sounds like you're dynamically loading content (rather than a normal page navigation event) but you didn't call ScrollTrigger.refresh() when everything is fully loaded and the DOM is set. I bet that's your problem. If not, please provide a minimal demo that clearly (and concisely) shows the issue and we'd be happy to take a peek. 

 

But again, ScrollTrigger.refresh() basically forces all the ScrollTriggers to recalculate their start/end positions.