ethanchiu10

It can support this IF you don't use any scrubbable ScrollTriggers that starts by entering the viewport in the rest of the page. I think this is a huge limitation. Anyway, thanks again for making the helper function, it is helpful indeed! In a few weeks time after my current project launches, let me share it with you here, I think a real example will clear everything up : )

I absolutely agree, and I'm not suggesting that it is a bug at all. It is very much a legitimate way of pinning, and has many uses that I've personally used also. But this method of pinning does not cover all use cases, and that's fine, that's why ScrollTrigger supports the pin option to let you pin something else. That's all awesome and great. I totally appreciate that a library such as this needs to be balanced against not only your effort, but also the file size and adding complexity to all projects that may use such a library. You are absolutely right to be extremely careful in adding only the necessary features that will help the most people. Also, thank you very much for your detailed example and helper function, I'll look in to implementing that to my current project! Finally, I do understand that maybe not many other users are asking for such a feature. Alas, I'm only one data point, and I know I don't represent everyone. But as far as I can tell, most scrolling sites could really benefit from this. I'll leave you with this: 1. Is pinning a section to do horizontal scrolling very common? 2. Are portrait window sizes very common? 3. Would many horizontal scrolling sections look better and/or more correct if they were not forced to be full height in portrait mode?

1. Previous / next section scrolls away wierdly. (lets call it "scroll" instead of "float" from now on, to avoid confusion) Minimal Demo https://codepen.io/ethanchiu10/pen/VwQgVgR Real Demo https://wisr.com.au/credit-scores Forewords First of all, I want to make sure we don't get off on the wrong foot here. I want to say most importantly that gsap is an amazing piece of software that can do a TON of things, and 'm a HUGE fan. I 100% appreciate how incredibly complicated and amazing this tool is. Personally I've been using your product throughout my entire career. https://ethanchiu.dev/ Every single one of those sites in my portfolio has used gsap, so THANK YOU THANK YOU THANK YOU for creating an amazing product, and to keep adding new cool libraries such as ScrollTrigger and ScrollSmoother! The fact that I haven't needed to post a single message on this forum throughout all these years is truly a testament to how many possible use cases gsap supports and how incredibly flexible this library is. You absolutely should be proud of it! With that said, I hope you are not too proud to think ScrollTrigger is already perfect after just 2 years of existence, and that there is no room for improvement. I hope you don't dismiss this issue because you perceive it is as niche and edge case and haven't heard a lot of complaints. I'm trying really hard to show you examples and prove to you why it is a VERY common use case. And I hope that you can recognise I'm a power user that wouldn't be posting if there wasn't a real issue. Obviously scroll trigger supports elements entering the viewport in portrait mode. But what I'm trying to tell you is, it does NOT support that IF you need to have the page pinned when a non-full height horizontal scrolling section comes in. The Problem 1. when a section needs horizontal scrolling, the entire page should pin instead of just that section. I don't want the previous/next sections to scroll away / in. [see scrolling away example at https://wisr.com.au/credit-scores] 2. the sections immediately below this pinned section should be allowed to have scrubbable scroll triggers that depends on entering the viewport. [e.g. parallax images] Work Arounds and Caveats Yes, work arounds exists, but each work around has non-ideal caveats. Either you have to 1. make all of your horizontal scrolling sections full height, in which case it looks wierd in portrait mode for a lot of designs 2. pin only the horizontal scrolling section instead of the whole page, in which case the prev/next sections scrolls out/in wierdly 3. pin the entire page, but then the scrubbable scroll triggers that depend on entering the viewport after the pin does not work correcly (as shown in the very first post) 4. pin the entire page, manually keep track of all the scroll triggers that are not part of the horizontal scrolling section, and toggle their playback (as shown by @akapowl)

@akapowlThank you! That is a very interesting solution. It does mean I have to manually keep track of all the scrolltriggers on the page, and pause/play all other scrolltriggers that are not part of the pin though. But let me give that a try!

Actually maybe this example is good enough to show you the issue already. https://wisr.com.au/credit-scores This page can be significantly improved in portrait mode if I could pin the entire page instead of only 1 section. But if I did that, and the immediate next section had any need for ScrollTrigger, it would break. Hope that clears things. If not, I'll show you more examples with videos in a few weeks.

Apologies, I don't mean to say it doesnt support it at all. It certainly can pin elements of any size, but with a huge caveat. 1. The previous/next element floats away in a wierd way, or; 2. Subsequent scrolltriggers will not run correctly unless you can guarantee they start after the pin. That means you are not allowed to use any scrolltrigger that triggers based on entering the viewport. In real world usage with a CMS, that basically makes it unusable. I personally have seen this issue since the very first site I used ScrollTrigger on https://goodmeat.co/ (solved by making everything full height) and soon after that on https://wisr.com.au/ (solved by letting prev/next sections float away wierdly) , but I never bothered to report it, as I'm sure many others have too. I think once my new project launches in 3 weeks, I'll be able to show you a really really clear example of why this is such a necessary feature. I think once you fully understand the issue, you will realize it is a very very common use case. 1. It is very common to view webpages in portrait mode (such as when your browser is using half the screen of a laptop) 2. Many sections of long scrolling sites should not be full height in portrait mode. 3. One of the most common use case for scroll triggers is to trigger an animation when the item has entered the viewport. Given these points, I hope you can appreciate how common and important this feature request truly is. I do want to add, I've loved using gsap for many years, it is an amazing product, thank you!

I really don't think non-full viewport height pinning is as rare and edge case as you think. I'll show you in a few weeks after my current project launches. I think it is a huge limitation of ScrollTrigger's pinning system. It essentially only supports pinning full height sections, and creates visual or logical bugs when they are not full height. I do appreciate and understand the difficulties in implementing it in to the current system though. Perhaps something to think about once you hear enough demand. Maybe it will warrant a rewrite of ScrollTrigger and/or its pinning system then.

The big issues is, if you only pin a section of the page, the sections before and after seems to float away and float in, and looks strange in a portrait sized window. To solve this, we need to pin the entire page instead of just a section. But doing so causes the other parallax images to have issue. This is a really common use case in my view. Just personally, I'm already on the 3rd project that could have used this feature. But I've just gotten around the issue by either A. pinning only the section and letting the previous/next sections float in/out, or more often B. stretching the section to full viewport height. In both cases, it looks visually wrong for tall windows (very common use case when a window is placed on one side of the screen).

Yes, the end positioning should be pushed down 1000px. But, also: 1. The parallax should not be animating while the page is pinned 2. Shouldn't this be done internally by ScrollTrigger? 3. How would all my subsequent parallax image components know whether it started before a pin (which requires adding extra px to the end), or after the pin (which does not require adding extra px to the end)? 4. How can we determine how much needs to be added? Do I need to add enough px for all previous pins? Or only the pin that overlaps? And is there a way to get the amount that needs to be added? Or do I need to calculate and store this myself?

@GreenSock I know the topic title makes this seem niche, but I really think this is critical for pinning non-full height sections. I'm happy to privately show you a pre-release version of my current project to show you why this is absolutely necessary.

Yea, I think the gist of the issue is, it seems pinneContainer only works if the trigger starts after the pin ends.

@Cassie Thank you for the quick response! But I feel that solution may be too specific to this one use case. For example, the current project Im working on is CMS driven using Vue. Pinned components or Parallax components (or other scroll trigger components) could be in any order. The parallax component (or other scroll trigger component) could come before and/or after the Pinned component, and have different start/end requirements unrelated to the Pinned component. Also, that solution loses the parallax effect when the image first enters the page. Would be nice to be able to solve it for scroll-smoother speed too.

It is very common to need pinned containers that have max heights instead of 100vh. In these cases, scroll triggers that comes after the pin, but starts before the pin will have its animation running even during the pin. See codepen for minimal example.