Jump to content

iDad5 last won the day on August 2 2022

iDad5 had the most liked content!


  • Posts

  • Joined

  • Last visited

  • Days Won


Everything posted by iDad5

  1. I found a solution and 'kind of' an explanation, even though I do not have had the time to fully understand the reasons things went south. I posted what I know on stack overflow, as it is not gsap related. (never could have been)
  2. Good idea, I will try to get that to work this weekend.
  3. It is indeed intriguing. 😬 As I tried to tell GreenSock in my explanations I tried to reduce it, but couldn’t really. I simply do not have interim states of my frantic refactoring session stored. I did no real browser testing during that time, I just changed references until it worked again and as I only had left 2 or 3 circular dependencies, for good measure I killed them off too. To be very frank, this was the first time I had to care about that, and my research into the subject left me rather confused. The whole native JS module thing is hard to research, as so much non native module clatter is overgrowing the information. I often read for 15 minutes before it became clear that the article was actually about Node.js modules. 🙁 I do understand that circular dependencies can become to complex to handle, but like in my case browsers handled a ton of them with me even realizing it. But once they broke, simply taking one or two out to add a new one didn’t work at all. I somehow cannot believe that those two things are really connected, especially as things broke on the painting side once the dependencies were cleared up. Also the module loading and parsing is long done bevorworte even the DOM is constructed But the unlucky connection of both things make it so challenging to really analyze the problem I’m a methodical way. I can (as soon as I have a little time) send you a link to the full thing (need to prepare a Version of it anyhow) if you are interested. I‘d try this via personal message then, as I feel this thread is about to overstay its welcome.
  4. Well it’s been a while, that I seriously tried, but as far as I remember there have been several browser inconsistencies, mainly Safari not doing things the same way as Firefox. Chrome on the other hand would ingnore transforms set by js and cloning nodes was impossible. Or I was simply not capable of doing it right. But maybe all of those issues have been fixed a long time ago. And won’t matter in the OPs usecase anyhow. I stand corrected.
  5. Thank you very much for your input. But I‘m sorry to say, that none of your competent tips are any news to me or the others that have looked at the problem. I have ample experience with all those methods and techniques. And even though I was certain that none of those had anything to do with the phenomenon I tried them all. The thing is that there is absolutely nothing remotely fancy in way of rendering on tis page. All of the problems that could be solved wit one of the tricks you mentioned could - at least in my experience - be seen in the dev-tools sometimes very deep inside but when knowing how to read them, the information given was consistent with the image rendered. With the more complex stuff, I admit sometimes no info can be found. But as I said there is nothing fancy at all, and simply toggling the class on and of in dev-tools „repair“ it. Regarding the Whisky - whenever you are in Munich a great dram will wait for you. Fair?
  6. In my experience the support for script inside SVG is very tricky, and browsers at handling it inconsistent. But I have to admit, that I always decided very soon not to go down that route after first tests. But it is great that @GreenSock have green light to try it every way you want to! Good luck!
  7. Funny, I was thinking of offering the same challenge in reverse but with something of real value as your price—a rare Japanese Single Malt not just money. That is surely true. I will attempt to do this eventually. Thing is, I stared out with this situation. Which was still working fine but refused to accept another module. It took me 8 frantic hours without leaving my chair to get to this situation. Without any functional change at all in the code, just changing references and import statements. The reason for all that was the pressing need for additional functionality (hence the new module). I solved the CSS(?) situation by taking out the position of the transition in question, and had to soldier on with the new functionality. Meanwhile, the project gained around a thousand lines of new code. Taking back in the transition for 'left' still has the same consequences. Going back to the version before the refactoring and working back through the 8 hours of restructuring will be a lot of work. If I find a way to restructure things in a way that do not have that side effect, I'm still left with all the new code added in the following days. And I probably still will not understand the reason for the issue in the first place. As I had the other issue at hand, you helped me with over the last week, as a second wildfire, I simply could not take the time needed when needed. Give the unusual nature of the problem, I hoped to find someone who had a similar issue before. Broken down to a simple question, it might be: How can it be that that dev tool of all browsers report a left value of zero, for a relatively positioned element in an absolute parent, while the rendering shows something entirely different? When toggling the one responsible class off and on, the values in dev-tools are 100% the same as before, but the element is rendered exactly where it is expected. Finding someone who can explain that could save me days (the rest of sanity I hold on to, probably too). And make a priceless bottle of Whisky change its owner.
  8. Actually, I'm sure it was way more than, 2000px, but with what Jack finally got in my thick skull in the other thread I can understand why it likely would not have worked. I thank you very much for all the time you spent on me. I sincerely hope that others might profit from that in the future so that it is not wasted on me alone.
  9. Thank you again, now I do not feel like a complete idiot anymore, only a normal one. I read that, but had not really internalized its consequence for 'my logic'. Now I learned. Against my better knowledge on a conscious level, it seems that under pressure I'm still deeply rooted in the assumption that all code execution in JavaScript is linear. Live and learn. Thanks!
  10. I know that I've earned a well-deserved reputation of not being able or willing to isolate problems, but talk much too much. The problem I have in this case simply cannot be replicated in a simple setup. In this case,—as I wrote on stackOveflow no scrip whatsoever is involved in positioning anything anywhere in the application. Yet, when I had to restructure a bundle of ES2022 modules to get rid of circular dependencies, this strange thing happened. The restructuring involved no new functionality—especially no functionality that changes any style value, as nothing in the project does. Everything is done by adding and removing classes. The CSS and the HTML, as well as the class names, are 100% unchanged before and after the restructuring. Whatever. I guess you are right. I will simply delete the thread. Sorry for being a bother once again.
  11. Thank you very much for your time and the great lesson. I don't doubt your word for a second, but as I do not destroy the timeline, I thought I was covered on that point. I will have to think that one through. But I accept your word for it as the gospel. That is so true and now that you tell me it is blindingly obvious. The only thing I can say in my defense is, that I was somewhat mislead by ScrollTrigger reporting to me, that it had set the scroll to the desired value—but that shouldn't have let me overlook my logical blunder. But wait, I'm still slow, I guess: In the case that worked, I set the height of the container to a multiple of the panel height right before the creation of the ScrollTrigger, that makes it possible to scroll the page. (True?) In the not working version originally, I had not lost the end value line, but set the end value to the same number I set the container height in the working version. (I corrected that again). As far as I understand and can see, when testing, that end value gives the pin-spacer the extra padding, to make the page scrollable. And the ScrollTrigger.scroll() is executed after the creation of ScrollTrigger. Even with that end value, it is not working and has never been. Is it possible, that the actual creation of the pin-spacer is only happening one refresh after the execution of the ScrollTrigger creation? Thank you for that. That in the CodePen I somehow lost the line that had been in all the time while I worked on it* makes me angry with myself. I had set it to 'scrollDistance' in all my local test cases and in the first version of the CodePen. (See above.) The misreporting on the label also happens without resize and on desktop, but all evidence points to a (timing) error on my side in this case too, I will look for that. Good to know, thanks. Yes, it does clear up a lot. Foremost, that you are a genius and that I want and need to understand thing better than I do. Thanks again!!!!
  12. I'm not really sure if I do fully understand what you want, and what's not working. To me, what you want sound a lot like you could use a ScrollTrigger that scrubs a timeline. You already have a timeline, but your ScrollTrigger is not using it, as far as I've seen. You can even build a timeline that hast child timelines, what by the look of things could add flexibility to the setup. But that likely would mean a lot of rewriting and rethinking, and if your current approach nearly there, it will not be worth it.
  13. As my full project has to kill and rebuild the ScrollTrigger on resize, that issue should be solved then. If the new issue had not occurred, while reimplementing my custom resize/refresh, we would likely have saved a lot of time and energy. But I would not have learned so much from you. Thank you so much for your patience.
  14. Thank you for the explanation. I have to think it through to fully understand it, I guess. But it sounds very much like the piece I was missing. (I was thinking in this direction already and had added generous extra space at some point to both variants, unsuccessfully, but I cannot be sure about the circumstance) I just now opened a new thread for the ScrollTrigger.scroll() problem. As this issue also occurs on desktop, I am quite certain it is not connected to what I just learned. Thank you again.
  15. Further details: Both versions use the beta of 3.11.5. I tested the problematic one with 3.11.4 to make sure it is not beta related. The behavior was the same. The lines 133 to 158 are necessary as the label reported from line 84 often is not correct. I don't think this is connected, but might be worth a look from someone above my mental pay grade. I needed to delay the resize trigger, as browsers fire the resize event much too frequently for the complex operations here. (I do the same but much more sophisticated in the production version.)
  16. Here is the working version: https://codepen.io/iDad5/pen/JjBVqmL
  17. The topic has the same context as this one and that one, but is not directly connected to those, as far as I can tell. It occurs on desktop Windows Chrome and Firefox, as well as Mac Safari. I did not verify other platforms, but have no reason to suspect that it is platform related. The CodePen is as minimal as I could make it without making is useless for me. It is in Typescript, which makes it a lot easier to read for me, unfortunately I'm aware that most others don't see it that way—even if I changed the coding style it would have still been rather complex. In fact, I have a working version with the exact same code, except for three lines. So, probably working through all the code will not be necessary anyhow. To reproduce the issue, scroll to any other panel than the first, and then resize the window. Expected behavior: after a rebuild of the page, the same panel as before the resize should be shown. Actual behavior: the first panel is always displayed after a resize. What is going on: After a resize, ScrollTrigger is killed and newly built. Then an attempt is made to send the new ScrollTrigger to the equivalent position the old one was in before the resize. The function used is ScrollTrigger.scroll(toValue); Line 55 in the code. While this works in one version, it does not in the other version. (I'll post the working version in the follow-up post) The difference between those versions is the method of creating (and recreating) the ScrollTrigger, it is to be found in lines 65, 68, and 69. Simply going with the working version is not an option, as this version has issues on mobile Safari, which this version has not. Moreover, I'm convinced that ScrollTrigger.scroll() should work in this version of creating the ScrollTrigger, which is working fine in any other respect as far as I can tell. Therefore, I suspect that either I do something 'illegal' in my code, which I'm not yet aware of, or there is a bug in ScrollTrigger.
  18. Technically, you would have to start by copying all the needed gasp files in script tags in the head. I'm uncertain if the license allows for that, might depend on the use case. You should ask the staff, if that's ok first I guess.
  19. Then we had a misunderstanding here, I thought by " without refresh enabled" you meant that ScrollTrigger's refresh is called onResize, as set or unset in ScrollTrigger.config(); That would be the column before pinSpacing in the spreadsheet. When using pinSpacing false, I do create the same amount of space to scroll by sizing the container to the combined height of all panels.
  20. That is not entirely what I understand, as two of the demos that snap have refresh disabled. I do not think so, as neither version has refresh enabled. As I said, I'm working on it, once I have it working I will post is as a new thread, I guess? There are things I would like to understand better 'here', but nothing that's really actionable or blocking next steps.
  21. That is likely the reason the 100vh in the body work better than the 100%, as I understand it now. At least the height of the body does not change that way, when the interface retracts. Why that makes a difference with the pinSpacing true approach, but does not help with the pinSpacing false method I do not understand.
  22. I cannot say exactly when it broke. I know that it worked (not supper smooth but mostly ok) on iPhone when we deployed the page, and the last time I extensively tested it on mobile, which must have been about half a year ago. As confirmed by/with Jack in this thread some change in a recent update made the way I worked with ScrollTrigger kill and create a new behave. I did not notice it at the time, as I did some testing on another page, but took only cursory glances at the front-page. This issue was solved by the 3.11.5 update. It solved the issue on desktop and on mobile too according to first test. But now on mobile, the not sticking to the last panel occurred. We did not have that in the past. I can only guess that it is related to browser-updates, maybe in relation to the new suppor for shv, lhv and dhv. Just a guess. Thanks to you all, I had a solution to both issues. But when I started using pinSpaceing true for the creation of the ScrollTrigger after the kill and rebuild, ScrollTrigger scroll() reported to be scrolled but was not on the screen. A different problem than before. (All Systems) Reverting to the pinSpaceing false method made everything work again, but left the iOS Problem. I'm working on a demo, but there's a lot of complexity to deal with.
  23. I doubt you can get this to work. SVG used to have a lot of fancy scripting functionality, but it was mostly deemed unsafe and is not interpreted by browsers. If full JavaScript execution as you would need it was ever possible—I doubt it. A self-contained HTML instead of an SVG is not an option? Or if the animations you require are not too complex you can go for CSS animations, those work inside SVG.
  24. 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.