iDad5

OK—I am somewhat lost and tired right now, so please forgive me if I'm totally on a wrong track with this one: While trying to fix my problem I decided to work on the mobile problems I never solved completely. One of them was that when over-scrolling the page on mobile, the fixed content could be forced to be scrolled out of view. I considered that a bug in mobile Safari, related to the 'over-scrolling' as position: fixed elements should simply stay on the page (as long as I don't move them by design - shouldn't they?). I was happy to read that mobile Safari finally (!) should honor 'scroll-behavior' and put in my CSS to NONE!. Now, after a lot of hair-pulling (debugging mobile…) I find that 'something' sets a style to my page's body with scroll-behavior: auto ???? As all pages without ScrollTriggers do not have that and all with ScrolltTriggers have that, I'm starting to lose faith. Is ScrollTrigger really messing with my page body's CSS?

Hi @TheSylvester it is indeed hard to understand that problem, but it looks similar/related to the one I'm having right now. I'm rather sure you are not crazy, at least not more than I am. There seems to be something off with ScrollTrigger and resizing. It is likely that Jack @GreenSock will swoop in with his magic cape billowing behind him, and his explanation will humble us mere humans - until then, rest assured that you are not crazy, but simply human—if there is a difference that is…

Hi, I'm stumbling around right now trying to solve my totally unrelated problem… The link opens to a project editor—which is a first for me—but interesting. I couldn't find out how to get the console in this view quickly so I just started up the normal dev-tools on the iFrame in question. There still seems to be the problem from before, that document.getElementsByClassName('fullpage-loader')[0]; leads you nowhere. I cannot find an element with the class: fullpage-loader anywhere in the htmlfiles....

I'm actually lost right now in a problem of my own, but as yours seemed related I checked, and it seems to me at a cursory glance that 'defererInstance' should be an Array of ScrollTrigger instances. So, you might have to execute update or refresh on the members, not on the array itself?

Thank you for your answer @Rodrigo. I tried the disabled method back then extensively, but as the height of the window might have changed, the whole metrics for the ScrollTrigger had to be renewed. As I mentioned, I might have worked with 3.11, but that just wasn't there. The scroll back is actually the only feasible solution I could come up with. I already do a lot “reverse -engineering” of CSS to get the correct position of the text-elements and grab the appropriate cut-outs from the image. Because of media-queries and some other “conditionals” in the CSS system trying to get the entire thing calculated is beyond me—and should not be necessary—as the system worked very well before. It is only the second time in a decade that a minor version update breaks things with Greensock. I really hope for a hint how to not have that refresh happen. I need to fix it, I already invested a lot of time in research, and rewriting stuff, but I cannot bill my client for that. As much as it might be a good thing to rewrite the whole thing from scratch—I simply cannot afford it right now. The complete thing is just shy of a thousand lines of code in typescript alone, not to mention PHP and CSS. I do hope for a magic hint from @GreenSock and fully expect to be humbled by it—feeling dumb for not having seen it myself. And yes, if needs be, I will (try to) build a CodePen instead of sleeping tonight. (Enough whining for the rest of the week—I promise.)

( I'm sorry for not being able to provide a simple CodePen right now. I hope you will understand my trouble without that.) I have built a ScrollTrigger page before ScrollTrigger 3.11 and its' responsive updates. I'm not 100% sure if I would have / could have built it another way with 3.11... My ScrollTrigger is Timeline-based, but I doubt that this makes a difference. On the outside, it is a rather simple full-page full-picture panel construct. But there is a catch: text (and a hamburger) on the picture-backgrounds that need to be readable. As I cannot predict upfront which text will be placed on what part of the picture, I must calculate the brightness/darkness of the areas where tests are placed. And I have to redo this with every resize. A resize triggers the following sequence: Kill the ScrollTrigger scroll the Window to 0, 0 (necessary for my brightness canvas-based calculations) check if I need better/larger pictures do my calculations recreate the ScrollTrigger scroll the window with ScrollTrigger.scroll() back to the panel that was in view before the resize happened. (Recalculated to the new value if height has changed) This used to work fine and was tested extensively. It is broken now (I guess since 3.11). What happens now is the following: after the above sequence is finished: ScrollTrigger updates and stays where it should be onEnter is triggered—still fine another update—still peachy and then a refresh is triggered (belatedly after some requestAnimaitionFrame calls) and self.scroll() reports to be scrolled to the absolute bottom of the window. (another update, where self.scroll() reports to be 0 and another refresh down to rock bottom follow) I have set: ScrollTrigger.config( { autoRefreshEvents: "load", } ); with hopes that this will avoid a (delayed) refresh to be triggered from the resize. It did not work. I do not understand why those two refreshes happen, nor do I understand why they scroll everything to the end of the ScrollTrigger. Can anyone give me a hint? Edit: I found the 3.11.5 beta and tried it too—did not change the behavior.

My standard advice would be to first build a timelline without scroll(-trigger) and once that does what you want add scroll trigger.

Great work as always! I'm impressed! You are giving us great tools to do the right things - but it also goes to show, how complex doing 'perfect' web-design/development... has become - especially once you realize that mobile and desktop (while gerat for tutorial explanations) aren't by far the only interesting environments and reduced-motion also has partners in crime with high contrast, dark mode etc... So thank you for giving us the option, and no thanks for taking away the excuses...

@Quang Anh Sorry, I've been rather busy the last weeks, and still am, so I cannot offer you help soon. I'm also not sure, if the effect you want to achieve really needs so much sophistication. A lot of times I find that a good 'fake' works just as well...

It might sound like a strange question, but why don't you just go for video? with all the effort you put in you surely could render several size videos that shouldn't be too large considering the kind of content you have. if you need some interactivity putting a small number of animated elements on top should visually work fine...

Well, there is no shame in not being able to follow @greensock as we are mere humans. 😬 I couldn’t follow his code especially on mobile right now. It might be that there is an (intentionally) undocumented property isPressed on Draggable, that‘s not in the definitions. haver your tried to use @ts-ignore to check if the code is working and it’s only a compiler issue?

I looked in the docs and there is no property ’isPressed’ so the first error seems very logical to me. the second one I’m not sure about as I’m on mobile in transit right now I cannot really check deeper. I’m not a fan of anonymous closures and have limited experience with proxy in TypeScript - so I might be wrong, but my strong suspicion is, that the constants xTo and yTo defined in the class are either not reachable through the Draggaable create or are inferred not correctly by the TS compiler simply by attaching them outside to the constant. in either case explicitly typing the constants and/or casting them to gasp should satisfy the compiler.

Depending on your actual use case it might be a good idea to set css-custom-properties to new values in you media-queries and use those in your css structure. That way you might only need to update I resize when an animation is running.

If you want to sync it precisely to the words, you could work with TexTrackCues that you would have to measure out and right down upfront. if there audio is distinctly pronounced with clear pauses between the words you could even try to determine them by parsing the actual ByteArray of the sound, but that’s likely overkill.

Had another idea: A option there would be combining two range sliders <input type="range"> visually into one. In modern browsers to my experience there is a good chance of getting the desired look and fallbacks are not too hard to implement. Linking both would need javascript event-listeners but if accessibility is a concern for you that could probably be the best option. (You can make controls you built with gsap accessible, butt doing _ in your case - might require some extra effort...)

You could (in theory) also duplicate the image itself if it is png or webp with transparency and use it as a mask and animate the the shine inside with a background position or css-custom-properties. That way you wouldn't need an svg for every image, if you need more than one. Even with using the css attribute selector maybe.... As i mentioned it is a theoretical possibility, and probably only worth the (testing-) effort id you need to be able to change the image via CMS or other frequent means. If that's the case, I'd be interested in the outcome, and happy to elaborate on my conceptual idea - without any guarantees...

Could you share a URL (via PN not publicly)? I'd try to take a look, and I promise my lips are sealed (Nobody listens to me anyhow ;-))

@GreenSock I actually had to look up how this works... It's a far too clever solution for me to ever use it though, as I might die of old age before figuring out what I have done there if I will ever have to revisit the code at some future point. Your deep deep understanding of that stuff never ceases to impress me.

That sounds (somewhat) understandable, as the browser surely knows more about the element's dimensions than JavaScript will tell us. In that case probably solution 3 or some variant would be the way I'd go. Maybe also a custom-cursor would do the trick (ignoring touch devices for now...) Knowing how 'magnifying' is supposed to work though would likely help in suggestion a solution.

Assuming, that the actual value you need is set/read only from one source anyhow, and not wanting to go into all the details of missing/not working cross-linked event-listeners, my suggestion would be to use CSS custom properties onDrag that all sliders are connected to. Percentages would even give you high flexibility.

MotionPathHelper is a separate Plugin, that you have to load to function. I'm not sure, if the rest is what you want though, because once you include the plugin, the helper path is drifting around

The ::after element isn't counting to the dimensions of the box element, as it is positioned absolutely and therefore out of the elements flow. It might be possible for Jack aka @GreenSock to apply some of his magic to try to consider absolutely positioned ::after and ::before (etc...) elements if the dragged element is a display parent - but that seems tough as accessing pseudo-elements wit JavaScript is near impossible... (not to mention shadow DOM et al...) So there are several feasible directions I'd see: - Changing the ::after element to a 'real' (JS-generated) element that count to the elements dimensions. - Changing the overflow (and scroll- ?) properties of the container so that the problem isn't visible. -Moving the magnifying-handle with script outside the container context with observer and maybe quickSetter()... there might be more...

Hi, (I could not reproduce it) I'd guess that the mouseleave fires not (correctly?) when you move fast enough to leave the window (browser window) - likely the mouse-events are pulled at some interval and when the mouse leaves the window before the event is fired, the event probably won't be fired at all. Well I'm not sure what browsers (ans OSs) do in that case, but it seems likely to be connected to something like that, as you say it does not happen as often on codePen - where leaving the window take somewhat longer usually. There might be a change of adding a window onblur event, but you should make sure that it only fires, if the conditions are right. And I have never used it in production and wouldn't be surprised if it came with restrictions...

Just to clarify my idea: I would use Observer, to do the video scrubbing. (Fixing the video or better its' container with css), then I would an EventListener ('ontimeupdate') on the video itself that would in turn trigger a timeline (or tween if that's enough) to animate the text in (and out....)

The thing is, that making responsive animations start with responsive layouts, and those used to me mostly percentages then we had hv and vw units, but now we also have css-custom-properties and calc - there is real magic in this combination.