Changing height on sticky element on scroll

[amitr95]

I have a panel (.fixedPanel) which is "sticky" when the element his the top of the screen. This element contains a large block of content, and since it is essentially "fixed" to the top on scroll, it takes up a lot of real estate on the screen.

 

To resolve this, once the element is sticky, I'm looking to reduce its body content height (.fixedPanel__body) to 0. Then to restore it's height when a user scrolls up  - like in the GSAP demos.

 

However, in my approach, the height is being adjusted even when I'm not scrolling, causing a glitchy effect visually. See GIF below.

 

To clarify, when a user scrolls down, all content in.fixedPanel__body should be hidden, until they scroll up.

 

Where am I going wrong?

 

 

See the Pen gOjVQmZ by amit_rai95 (@amit_rai95) on CodePen

[GreenSock]

The fundamental problem is that you're animating the height of an element that's in the document flow, so it's literally changing the entire scrollable area and shoving things around, likely affecting the scroll position as well which causes the direction to vibrate back and forth. Not only is that pretty terrible for performance (document reflow is bad), but if you've got ScrollTriggers on elements further down, you'll be throwing off all those positions, so you'd need to call ScrollTrigger.refresh() to have them recalculated (again, expensive). I'd strongly recommend not animating the height of an element that's in the document flow. Animating the scaleY instead is far, far better in terms of performance (but obviously it looks different). 

 

Here's a fork that does a console.log() to show you when direction changes and I added conditional logic to skip it if the animation is in progress. I don't really recommend that as a solution - I'm just trying to show you what's going on. Remove my conditional logic and watch the console.log() go nuts. 

See the Pen RwBXEYr?editors=1010 by GreenSock (@GreenSock) on CodePen

 

If you really must animation the height, I spent some time crafting a potential solution that involves setting up two Observers - one for wheel/touch events and another for scroll events: 

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

 

I hope that helps!

[amitr95]

@GreenSock

 

Thanks for explaining the issue with height. I concur it's not best for performance as my Mac was going nuts recalculating the height!

 

Curious regarding the scaleY approach however. The reason I didn't adopt a scale, display or visibility approach is because I'm also looking to remove the "height" of .fixedPanel__body on scroll down, so that only the price shows (and provided more real estate on screen).

 

Whilst scaleY does hide the element smoothly on scroll, the height of .fixedPanel__body still remains (which is why I went down the route of height).

 

For example, see my updated demo below. When scrolling down, overall height of .fixedPanel still stays the same. How would scaleY be feasible in this use case?

 

P.s. Appreciate the time you have spent devising and explaining the height approach via two Observers 

 

 

[GreenSock]

No, that's the fundamental problem. If you want the actual height to change, that is going to create the problem you originally posted about. One of the reasons scaleY is so much more performant and it doesn't mess with the scroll position or page height is that it has no effect whatsoever on the document flow. Think of it like just squishing/stretching the pixels of that one element.