Jump to content
Search Community

ScrollTrigger - Pinning in different scroller than body

akapowl test
Moderator Tag

Recommended Posts

Hello everyone,

I am slowly getting the feeling, that I am severely miss-using ScrollTrigger, and by now I am feeling pretty bad for always bothering you guys.

I have tried about everything that came to my mind and still can't wrap my head around this.

 

I know this might be a bit much to process, but I'll ask anyways.

Maybe someone finds the time to help me dig into this.

 

As several times before, there is that thing with the horizontal translation of the content in a section when scrolling vertically.

 

Everything is working just wonderfully, when the body is the scroller, just like in this pen:

 

 

But I have this scenario, where I can not have the body be the scroller.

So I set the body to overflow: hidden and a div inside the body to be the element that is being scrolled instead.

 

When doing that, the pins did not seem to work the way they worked before and went all wonky, which can be seen here:

See the Pen 0a02364ff4521d80fc2b80ce5430fdbb by akapowl (@akapowl) on CodePen

 

 

I thought, that might have to do with me pinning the wraps inside of the sections, instead of the sections themselves, so I tried pinning the sections themselves instead, which resulted in this:

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

 

 

At first glance, the pins appear to be working correctly, but especially on mobile you can see, that the somewhat "lag behind" - don't know how else to describe it - depending on speed and direction they tend to be pushed up/down in scrolling direction. I thought this might be a case for reparenting the pin but it didn't work.

 

Additionaly to that, the different sections sections don't seem to have the correct background-color applied to them anymore.

 

 

 

So to finish things up, I guess my questions are:

 

Am I doing something horribly wrong here?  (Like; am I preventing ScrollTrigger to get the right values for it to be working properly?)

 

Is this sort of scenario to be avoided in the first place, when working with ScrollTrigger?

 

And/or might there be a work-around for me to get the same behaviour as in the first of those three pens, where the body is the scroller?

 

 

 

Sorry for the long post 🙈

Cheers,

Paul

 

 

See the Pen 8a383f202ba53d6b11cc83da39b6f5b5 by akapowl (@akapowl) on CodePen

Link to comment
Share on other sites

19 minutes ago, akapowl said:

the different sections sections don't seem to have the correct background-color applied to them anymore.

This is because of your CSS: section:nth-of-type(odd). Since pinning a section adds a parent container, all of your sections will be the first child and match this rule. To fix it, modify your selector to work with the new layout (for example .pin-spacer:nth-of-type(odd) section).

 

23 minutes ago, akapowl said:

I have this scenario, where I can not have the body be the scroller.

I'm curious: why is that?

 

39 minutes ago, akapowl said:

especially on mobile you can see, that the somewhat "lag behind" - don't know how else to describe it - depending on speed and direction they tend to be pushed up/down in scrolling direction

I think this is just because the scrolling thread is separate from the main JS thread. So the default touch to scroll action is happening and then some time later it reports that change and ScrollTrigger updates to the correct value. I don't know if there's anything we can do to improve here. @GreenSock have any thoughts?

  • Like 1
Link to comment
Share on other sites

1 hour ago, ZachSaucier said:

This is because of your CSS: section:nth-of-type(odd). Since pinning a section adds a parent container, all of your sections will be the first child and match this rule. To fix it, modify your selector to work with the new layout (for example .pin-spacer:nth-of-type(odd) section).

 

That makes total sense.

Thanks @ZachSaucier

 

 

1 hour ago, ZachSaucier said:

I'm curious: why is that?

 

"Can not have" might have been a bit strong - Actually, I totally could.

It is part of preventing the browser-built-in navigation-bars to disappear on scroll/swipe on mobile devices.

You know how working with viewheight based values can be a pain sometimes in regard to mobile, right?

When no transition applied, elements tend to just jump into place when the browser-bars disappear/re-appear.

And with regards to look and feel of a page that can be pretty disruptive in a way. 

I know preventing the default browser behaviour can hurt usability - don't judge me please 🙈 .

 

 

 

1 hour ago, ZachSaucier said:

I think this is just because the scrolling thread is separate from the main JS thread. So the default touch to scroll action is happening and then some time later it reports that change and ScrollTrigger updates to the correct value. I don't know if there's anything we can do to improve here.

 

Sounds like that is just due to how browsers work then!?

...sort of fits the theme here.

 

Link to comment
Share on other sites

Yeah, the crux of the problem is that most modern browsers handle scrolling on a totally different thread which is super annoying in cases like this because you CANNOT synchronize things. So ScrollTrigger is accurately setting the transform values to make the element appear "stuck" (fixed) but the browser is moving the WHOLE page for the scroll briefly before it renders the changes that ScrollTrigger made via the main JS thread. 

 

One thing that could solve this in your case is to use position: fixed for the pinning so that things are totally taken out of the scrolling context. By default, however, ScrollTrigger only uses position: fixed for pinning when the scroller is the <body>/<html>. You created a wrapper <div>, though. Once you start nesting things, position: fixed often isn't viable because if there are any transforms (even transform: translate(0px, 0px)) or will-change: transform, it creates a new rendering context in the browser and descendant elements will move with that element even if position: fixed is applied! Weird, I know. Technically it's proper behavior but almost nobody thinks that's intuitive :)

 

In your case, since you've got your scroller set up as position: fixed, it should be safe to do the pinning with position: fixed. Here's a trick to force that:

ScrollTrigger.scrollerProxy(".full-height-container", {	pinType: "fixed" });

That seems to work pretty well for me. Does it solve the issue on your end? 

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

 

8 hours ago, GreenSock said:

In your case, since you've got your scroller set up as position: fixed, it should be safe to do the pinning with position: fixed. Here's a trick to force that:


ScrollTrigger.scrollerProxy(".full-height-container", {	pinType: "fixed" });

That seems to work pretty well for me. Does it solve the issue on your end? 

 

 

Yes, it absolutely does solve the issues. Thank you, @GreenSock !!!

 

I just had to add a little 'pointer-events: none' to all my pinned sections, additionaly to your suggestion, to make sure that I can still be scrolling/swiping on, when the section is fully in viewport. But now the pins appear truly pinned.

 

 

And I will say that, actually I was kind of close to getting to this myself.

I had tried applying the .scrollerProxy with 'pinType: "fixed' but at the same time I was giving ScrollTrigger different 'directions' via .scrollerProxy with this

 

scrollTop(value) {
 	if (arguments.length) {
 		$(".full-height-container").scrollTop() = value;
	}
	return $(".full-height-container").scrollTop();
}

 

because I was under the impression that it might be needing the scroll-values from that container.

But I guess by doing that, I changed the context myself once again, so the pinType: "fixed" did not do what I was expecting it to do. 

 

 

So, thanks a whole lot for your help with finding a solution, but even more for your in-depth explanation, making things a bit clearer to me!

Cheers

  • Like 3
Link to comment
Share on other sites

  • 2 weeks 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...