Following a previous question, I’d like to propose a little challenge to the community since I’ve been told this was impossible to achieve with Webflow native interactions.
That would imply an alternative onClick interaction that directs the user directly to a % from a “while scrolling” IX.
FYI:
Standard HTML section #anchor doesn’t work;
onClick interactions that vertically move the trigger_DIV seem to conflict with the “while scrolling” IX (that would have been the most logical option);
onClick interactions that move the container on the X-axis break the site when we start scrolling again.
I’m very curious to see what you guys come up with.
Just the ones you want and it’s future proof in the sense that webflow is moving to GSAP eventually. They bought the company and IX2 kinda sucks and has many limitations.
The main issue is that you’re using WF interactions which doesn’t give any control or feedback within the interaction.
In your case the entire “play” is orchestrated from a timeline that is controlled from the mousewheel, between 0% and 100%. It’s an excellent design pattern, but since you apparently cannot directly tell IX2 to seek to a particular place in that timeline, and you cannot determine where in the timeline you currently are, you’re somewhat stuck.
This is an idea for a super-crude-hack, but maybe you can build that controller on top of IX2, in two parts;
Add a hidden element with a height that is directly bound to the timeline. Checking the height of that element in custom code gives you a good understanding of where you are % wise in the timeline.
See if you can mimic mouswheel events in a way that IX2 will honor, to move the timeline forward/backwards as if the user were manually choosing that.
With those two together, you could seek to e.g. 58% by using events and the hidden feedback element to seek you to that position in your animation, while fully preserving the internal state of IX2 so you don’t break everything by shifting elements externally.
It might even be possible to take this further, where a specific element’s horizontal position could be watched until it falls within a target range, and then the scroll events stop. Since you’re working with estimations, you might get a bouncy effect but that could also be kind of cool.
A fair bit of R&D to even determine if you can make this work but the big advantage of that second design is that it will be fully responsive.
I have not heard any details at all regarding IX3 and GSAP but I sincerely hope the internals of the interaction state won’t be locked away. This is a perfect example of why that severely limits great UX designs.