Browser: Chrome 110 OS: macOS / Windows / Linux / etc. URL: Link to a page that illustrates this issue Video: Short screen recording that illustrates this issue (free tool: jam.dev)
[Please describe this bug in as much detail as possible so we can replicate & debug this bug]
Hi
Using Interactions as so, based on scrolling to element and to fire where I add a class:
I tried âenter viewportâ as well, but on some instances, like on here, they just keep looping on scroll and feel quite buggy. Is this normal, and is there something else I should be doing? https://whitespace.agency/services/digital-marketing/
Oddly some uses of it work well, and others are just very glitchy.
Unfortunately, I cannot reproduce the issue. Would you be so kind as to send temporary login credentials and a link to this thread to help@bricksbuilder.io using the email address you used during the purchase?
Thanks for the access data! There is indeed something strange with the ârun only onceâ setting, if the interaction is directly applied to the loop item. It seems as if the interaction runs for all of the items first and then independently for each item again.
If I put the interaction on the ul and choose each li as selector (see " Digital Marketing Servicesâ ul/li), the run only once setting works as far as I can tell.
However, you will then no longer have this staggered animation effectâŠ
The devs need to look at this in detail
OK that makes sense and glad itâs not just me. Luckily Iâve used a class for it, so whatâs the best bet for now - remove the interaction via Bricks and add the enter viewport code manually until this is solved?
OK Iâll give that a go. So essentially it depends where the interaction is sat? I must admit the interactions confused me to death as you can attach it to a class, and if you create it on the class, then you can edit it. But if itâs created on the ID but still attached to run on a class, you have to them remember which ID you created it on to locate it.
I have the animations running in various places. I am using BricksForge and GSAP, with pinned sections - I wonder if this is upsetting the viewport detection?
If you use the same interaction/class with the interaction in other places, it will of course be difficult to make an egg-laying wool-milk sow out of it as long as the problem persists
Thank you. Yes I was just trying to use fade-in-up (like I used to use in Oxygen or similar) to reveal animations on scroll so was trying to keep the classes to a minimum
Is this something that will be looked into fairly soon do you think Stefan, or should I hold off for a bit?
Thanks for the reply. That was for data-animate I was using as a fallback when this wasnt working, to add css to that rule as I was having to get it to add/remove the CSS based on scroll, so the animation did not loop?
In this instance no style is being added so that should affect anything, but I will remove it too.
If I add the condition to a class now, do I need to tell it to target the class, or will it add that condition to every class ?
Removed that data-attribute bit (even though it wasnât being used) on that page Stefan and still happening annoyingly. I have ticked run only once also
Youâre right there yeah, thatâs a strange one in that case
I am using GSAP with Bricksforge, but thatâs the same for both of those pages.
I used the add/remove attribute when in viewport before, in interactions, and that seemed to work. I was just hoping I could use the native one now but still seems a bit janky/re-reunning for whatever reason on the single work pages.
Unfortunately, as I said, I cannot reproduce the problem as I do not use Bricksforge. However, the first step would be to deactivate Bricksforge and see if it then works. If this is the case, please contact Bricksforge.
