iDad5

By standalone, you mean outside a HTML page, I guess? I would say no, as GSAP is JavaScript, and it needs a browser to be run. But maybe there is a solution depending on where you want to view/present the SVG, you would need to give more details, though.

Short hint: You can also set more than one background image when using the background property instead of the background-image property. Programmatically removing the topmost (with a class change or direct access to the element.style) might be an option to explore if you are forced to use a background-image.

By the way, if you are still interested, according to my tests 3.11.5 behaves the same in all test cases as 3.11.4

That's the reason for all my tedious descriptions: When I started integrating 'Panels in Body II' (the one working solution I had at the time) my actual project, scrollTrigger.scroll(toPosition) stopped working. It did work with 'Panels in Body' though - which did not work on iOS. The scrollTrigger.scroll(toPosition) is vital to work, as it allows me after a rebuild (due to refresh) to go to the correct position before the resize. As the whole problem started with a malfunction of this part, which jack fixed in the beta. I decided to go back, trying to understand what really causes the 'not sticking on last panel in iOS' issue. It seemed the easier issue to solve at the time. Especially, it is one that can be reproduced in a smaller demo. By now, I still don't really understand why the 4 demos that do not work on iOS do not work, but I do understand some more. The page we are talking about is the front page on one of my most important customers. It has not been working on mobile now for over 2 weeks. The system that powers it is very complex, but the panel-mechanism we are looking at is the core of it. When I made small changes to the code for the demo, I did not understand the outcome. I do not want to rebuild the whole system around a core component that behaves in a way I don't understand. (Reassembling the system with the updated core, testing it, and deploying it to the site means hours of work each time.) I had a page that was working for over a year and that stopped working, and I did not understand why for quite a while. A lot is on the line for me in this situation, and I feel the need to really understand what is happening and why, and I need to be confident that the solution I find will work. EDIT: I also continued the thread, as I do feel that there are things in ScrollTrigger that do not work as expected, and that I can help to point out so that they can be fixed.

Sorry, I was hunting for the console.log line you commented in your version. My bad. I'm fine with that. To answer your questions: My ideal behavior would be indeed snapping to the last panel in iOS. Even more ideal would be if no internal event loop happened when is snaps to the last label, but I can live/deal with that. I would prefer if refresh on resize could be disabled, as in the final version I have/need my own resize handling. But it is not a must-have as far as I can see. New finding: By comparing the compiled HTML code, I found a difference between the 'Panels in Body II' and 'Panels PinSpacing true' that I wasn't aware of and that made the difference I was hunting for. The first set the body height to 100vh, the latter to 100% (HTML height 10% at both). With that change Panels PinSpacing true is snapping to the last panel on iOS. I added that change to the table (before your message with a new pen—sorry) I will now change all pens to the 3.11.5 versions.

Thank you for that. But I don't understand exactly what you want to tell me with that post. There is no longer a typo in my window demo, and I cannot remember that the window demo ever made trouble on desktop. The typo after all only means that 'undefined' would be logged. Does your coming back to the window demo mean that you want me to return to this route? Or is meant as general advice for anyone having trouble wit iOS jitters? Or is it meant as an example of how to better report on issues?

Here is the table: https://docs.google.com/spreadsheets/d/1jyFP1ZT2jszrJKRIMQXtWpl2Wzln2YDartEVW-fIb2o/edit?usp=sharing [All demos work as expected on desktop—the problem (not snapping to last panel) is only occurring on apple handheld devices] And all demos right now use the current stable versions of 3.11.4 of gsap core and ScrollTrigger

Yes, sorry I'm dyslexic—will fix, but as I said I abandoned the window version a while ago because of pinType transform. When I edit it, I cannot find it anymore . Could It be that you have a cached version?

Seems to do well now?

Hi, had a look at the video. I'm not like to be able to help you myself, but you might get help if you get a bit more specific. The video you posted shows one animation, that could basically be a video, as it seems to play the same way always. Does the speed with which you swipe up influence the animation? (could still be just a video then, but with speed / scrub control). Or does the position of the finger changed the animation? Then you need something like gsap... The answers to those questions influence the complexity and thus the amount of work involved a lot.

I have a really strange behavior in a project with CSS Transitions. I cannot pay a lot, but I would try to compensate as best I can. I posted the hard to describe problem on stack-overflow as it is not gsap related, but aside from downvotes and edits I got no replies. https://stackoverflow.com/questions/75322030/unexplainable-css-positioning-issue-somehow-related-to-transitions As a lot of the best front-end geniuses I know are active in those forums, I thought I give it a try to ask for help here. Please contact me if you feel you might be able to contribute.

Thanks, I probably should have tried it the way you showed before asking dumb questions… Jack sent my a link to the ScrollTrigger Beta only, so I can use this in my local environment, but a whole zip would likely be very helpful, to reduce the small risk that ScrollTrigger 3.11.5 has an issue with gsap 3.11.4.

Here is my try at pure facts and a table: The 'body' vs. 'window' Version showed that the Type:'transform' was unusable on iOS because it always jittered too much. 'Panels in Body' however did not snap to the last panel on iOS. 'Panels in Body II' changed the method of giving scroll-space to the ScrollTrigger from pinSpacing:false to pinSpacing:true. (What I called method a and method B ) 'Panels in Body II' did snap (to the last panel) on iOS. This could have been the solution, but when trying to integrate 'Panels in Body II' into the project, other things stopped working. So, I went back to test for other ways to solve the 'not snapping to the last panel on iOS' I reduced the code from the Panels in Body demos by removing the Panels class and reducing the PanelManager to the bare minimum of functions. I tried not to make changes that would affect the scrollTrigger. 'Panels PinSpacing true' is the reduced Version of 'Panels in Body II', 'Panels PinSpacing false' is the reduced Version of 'Panels in Body', Both reduced versions did not snap at the last Panel. When I remove the configuration to not refresh on resize, 'Panels PinSpacing false' snaps, while Panels 'PinSpacing true' does not. (Ia added those versions too with the addition of 'no config to' the name.) Table: *iDad scratches his gray head* how do I insert a table here?

Thank you, but I have a dumb question: How do I use them?

Thank you for your dedication @Cassie I will prepare a table—might take a little while, though. I asked for a way to test with version 3.11.5 on CodePen a while ago, but never got a solution, do you have one?

Without any more melodrama: I had prepared a stripped down but proven version of my project locally. Jack helped me resolve the issue of not being able to go back to the previously shown panel after my custom refresh/kill-recreation. I found that my way of creating the ScrollTrigger for over a year (version a) was no longer working on iOS/iPadOS (the middle finger emoji for Apple here) I found a solution for Apple's f… up—with version B. Or, so I thought. When I applied version B to my simplified project version, the previously perfect solution from Jack did not work (and the 3.11.4 version also) did nothing. Guessing that it must have been my fault with version A/B I simplified… —with the well-known consequences.

I thought so, but once I reduced it (mostly taking out the Typescript structure that I find much better to understand, but you don't) it turned around on me. While I had the 'main problem' not even touched. (If that sound delusional to you, don't feel bad, it sounds the same to me…)

Essentially, yes. Moreover, I had always found a “solution” that worked smoothly with fixed transitions. But for completely incomprehensible reasons' version A / B—one/tow whatever broke down again at the slightest change of nothing at all. If you ever feel so happy that you want something to get you back down to earth, try reading this thread and the one preceding it. Word for word—with a great glass of Tuscan wine or—even better—an old Scottish or Japanese single malt if you like those (I'll send you a big sample—I do mean it!) and cry with me. I'm utterly lost for now, have to let one of my most valued customers down, and don't understand why—A and B—you know it. I will follow your advice of layering another complexity (ScrollSmoother) on top of a thing that is too complex for me to understand—against every principle I've made my own n in over half a century on this planet. Tomorrow.

It snaps when I follow the link from your post directly, likely as I'm getting a non logged in version where the actual code is buried deep in an iframe. I don't understand why I get this version. When I follow the link from my codePen into the plain debug version, this version, it does not snap. The version of that iteration that snaps is https://codepen.io/iDad5/pen/yLqwXBp But maybe you get a different version from me. I abandoned the “window” approach on Saturday as it was always very jittery, even your super simplified version looks bad on an iPhone 12 proMax. No it does not, it sticks after a lot of jittering at some point. It looks like, but as the “window” approach seems to be not working for me, this might be a moot point. I'm sorry that I am/was so annoying. Thank you very much for your patience. FYI: Your last link opens in a non iframe / debug version for me, in contrast to the first two links. I don't understand why this is.

Small caveat here from me, as I'm fighting with this issue for a while now: Is true in most cases, but not always: On (mobile and tablet) browsers that overlay the content with interface elements like the address-bar, which will be retracted when scrolling, this is not true. Here is a short list of things that might be helpful to remember: window.innerHight (and the equivalent innerWidth) resemble the total space of the viewport, including visible scrollbars. document.documentElement.clientHeight (and width) measure the space excluding visible scrollbars. 100vh is the same as window.innerHight as long as there is no expanding browser interface. If there is an expanding browser interface, usually only the height is affected, and usually 100vh resemble the height of the viewport once the dynamic interface is retracted/hidden. (But there is no guarantee, as the specs leave it to the browser vendors how to deal with it.) 3 new units that are already quite well-supported come to the rescue, however: 100svh resemble the height of the visible/usable viewport when the interface is fully present. 100lvh resemble the height oft the visible viewport when the dynamic interface is fully hidden. 100dhv resemble the height of actually the visible viewport at every moment. (It is not guaranteed to be updated as fast as the browser renders, however.) An illustrated in depth description can be found here: https://github.com/web-platform-tests/interop-2022-viewport/blob/main/explainers/viewport-units.md

TLDR: Yes, I do have two simple solutions for one simple problem*. I would not bother anyone in the forum if looking at those, in isolation, could solve my issue. It is the confusing part that I'm lost in. I understand that no one likes the confusing part and would like me to break it down in easy to solve bits. But I already did that on my own. I take things apart, fix them isolated, but when I put them back together things break again—in another way. I try again, as I'm desperate, but I do understand that I cannot expect anyone to take the time and effort to dig through the confusing part. And I'm already and forever grateful for all the time anyone has put into my difficulties. That is not the problem, as far as I understand it. The way things are built, neither the body nor any other container change size (height) when the address bar is retracting or expanding again. I have verified that in the dev-tools on my connected Mac often. But I will dig deeper into that as soon as I can. (In my original project, I either have to deal with a resize in more ways than the re-layout of the ScrollTrigger, that's why I kill and rebuild it. Alternatively, I will have to make sure not to let the content change its size, which I do now.) Yes, I fully understand that this is frustrating. No one better than me because I suffer with the situation for days now, each time I thought I fund a reproducible solution for one difficulty, the thing behaves the other way around in the next step. I'm certain that your brain—even in covid-mode—is much superior to mine. The 'not snapping at the last panel on iOS' problem I'm having right now, I though was solved by using Version B. And it was consistently until it did no longer. In the next step, I went on to cautiously trying to implement my 'rebuild on resize' method. (The one that had broken before after working for over a year, and you helped me fix it in the last thread with the beta version of ScrollTrigger 3.11.5.) Everything seemed to work, except the last step that should send the system back to the panel it showed before the resize. (that had worked on Saturday with version A—before I stumbled over the 'not snapping at the last panel on iOS' thing) ScrollTrigger reported (logged) that It was at the intended position, but it didn't show at the scrollbar or the timeline. Even manually sending the time-line to the desired position of forcing a ScrollTrigger update did not change a thing, on any system. While researching into that issue, I found that the not snapping on iOS had reappeared, for no reason I could find. So, I went back a step and tried to understand and solve the 'not snapping at the last panel on iOS' again. (Any workaround to that problem would likely involve me manually setting the ScrollTrigger scroll() and/or the timeline...) *the two isolated problems: That is exactly the case in demo 3 as stated there: My statement likely became unclear due to the unsless 'on' and the embedded CodePen which replaced the linked text 'here'. The fact that in this one case there is an easy to see causality and solution in itself is worth nothing. The solution (to simply not limit refresh), would work in this case, but it does not in the next even though it works the same way. I have a similar situation with 'Version B' as solution. It itself is five-year-old-friendly: demo 1 does not snap at the last panel, changing ScrollTrigger creation to Version B makes it work. So, the broken down and simplified versions you wish for I have already shown them here, including their supposed solutions. But those lead me nowhere.

Asking for a friend: Is there a way to link to a code pen without it killing being embedded? I feel that is not helpful in this case, as I only wanted to reference those in the text.

Greetings Jack @GreenSock from the outskirts of Oblivion. First and foremost: it is great to hear that you are 'out and about'—sounds a lot better than ill. The thing with 'super clear steps' in that case is that to me by now nothing feels super clear anymore, but I'll try again: I do hope you can stay with me, even as it is not what you (and i) wished for. If not, I do understand it and simply will give up with no hard feelings at all – but thankful for your patience always. Let me start with: 1. (As far as I can tell) all demos act as expected* on all browsers I tested them on, except for iOS / iPadOS! (Expected behavior* should be seen by scrolling up and down in any browser not on iOS/iPadOS, namely staying at the last panel when scrolled down to.) 2. To experience unexpected/strange behavior, testing on iPhone or iPad (current OS version) is required. 3. Of the two versions posted in this post, only the one with 'version B' works as expected. 4. Simply going with version B (https://codepen.io/iDad5/pen/OJwqjQB) ceased to be an option when this version did show unexpected behavior (simply not working) in all browsers and systems. When I used ScrollTrigger.scroll(value) as, I tried to go with this approach in a very simplified version of my project. (Let me name it the main problem—which is not yet described and investigated further) FULL STOP. I do understand what @Cassie and @GreenSock keep repeating at me. I've been in your shoes countless times! Gave the same advice too. But there can be problems that are innately ones of complexity, and to me, this seems to be one of them. So, as hard as I try—and please believe me I do—I'm simply not able to reduce it to more simplicity. ____ Heating your advice, I put aside investigation of the “main problem” for now, and tried to narrow down or 'simple demo' the first problem by simplifying my demo further: [Simplifying mostly meaning taking out Typescript structuring while the actual programming is nearly identical] And what happened then I tried to describe here. (Please remember, we are back to exclusively iOS/iPadOS faulty behavior here) I rephrase: The only difference between demo 1 and demo 2 is the difference I describe between version A and version B. From those two (on iOS) only version B (demo 2) worked as expected*. Version A always behaves faulty with the last panel/label. (Spoiler: Both always used 'only auto-refresh on DOMContentLoaded'); One of the few things, my first more simplified demo (beta 3) did not use was the 'only auto-refresh on DOMContentLoaded' configuration—as I wasn't interested in refreshing—yet. Surprisingly, hat first demo (beta demo 3) did work as expected* (staying at the last panel when scrolled down to it) on iOS despite using version A. You (hopefully) can reproduce that by commenting on lines 22 and following in and out in demo 3—testing on iOS/iPadOS. (For me commented out it works in iOS, commented in it never sticks at the last panel/label). [I do not comprehend how that 'only auto-refresh on DOMContentLoaded' does change behavior (even only on iOS) when no refresh (aside from the initial one) is involved in my testing. (I logged it to be certain).] The next step was to fork demo 3 and changing ScrollTrigger creation to method B. Given all prior test (manifested in demo1 and demo2) I was confident that demo 4 (B version of demo 3) would behave as expected*, like demo 2 does. (Demo 2 was created the same way from demo 1) But for me, demo 4 does never stick to the last panel weather I comment the 'only auto-refresh on DOMContentLoaded' configuration in or out (line 22… | and still only talking about iOS.) I always liked Kafka—but never expected to meet his world in programming, but to me, it feels like I fell into one of his stories with this. As long as I don't understand what makes one version behave as expected and the other one not, I don't see how to continue tackling the 'main problem'. I know that iOS is to blame for the disaster in general. But somehow I doubt that the ghost of Steve Jobs haunts my four devices consistently with evil genius, to torment me. Therefore, I suspect that part of that strange behavior must be either my bad programming or a (in this fringe case) too genius programming in ScrollTrigger. I'm at a total loss, though—once again. *Expected / unexpected behavior:

It gets more confusing by the minute. I reduced the example as much as possible, without fully losing the chance of tackling the next problem. It is down to around 50 lines of code. But it does essentially the exact same thing as before. At first, I was surprised that method A worked on iOS—and after some testing, I found that I stopped working when I added: ScrollTrigger.config( { autoRefreshEvents: "DOMContentLoaded" } ); You can try by commenting in and out lines 22 following here: https://codepen.io/iDad5/pen/ZEjPeMQ Then I forked it and changed to method B, fully expecting it to work with and without the above config. https://codepen.io/iDad5/pen/OJwqjQB Well, to my total surprise, it does NOT work in both situations. So, while the previous version with more lines of code, but essentially the same programming, does work only in version B and even with the config enabled. The striped-down version works only in version A without the config. I think I need to drink myself to oblivion. ? And finally admit that I'm too dumb for programming.

I know, and I am working on getting closer to the behavior from a even more simplified version. But as the only difference between the two versions is in the three lines I described, the additional Code should not be of real concern. I t might be a long shot, but I was hoping that some one would have had a similar Problem and could reduce the need for further work on that (probably) side issue. As the behavior is so hard to pinpoint I was also really wondering if it is related to my devices only. FYI: I could happily go with version B if not an other more severe Problem had occurred. With version B ScrollTrigger.scroll(position) does not work as it did with version A before. At least in my Allred very much reduced local test version. That was what I was actually trying to pinpoint, and I felt that I had to pin down the A B situation as best I could. Thank you for your patience.