eballeste_hero

It does clear things up, I knew I wasn't crazy 😮‍💨. Thanks for all of the details, I knew these browsers were doing something funny, it just didn't make any sense at all. I guess I have to figure out how to get rid of the overflow:hidden rule. It has nothing to do with the overflow rule, it's just something that happens when the container is extra tall like you said. Again, thanks!

I updated the post's title because this has to be some sort of bug right? I cleaned out my last version of the jsFiddle, reduced it to the bare minimum and it still consistently shows the visual break on top. Not sure what is causing it though, there's no clipping because if you reverse the animation of the visible elements they aren't hiding. https://jsfiddle.net/r3fokdvm/15/show

@GreenSock I found the issue, but don't know what the answer is. It seems that the visibility of the animation breaks when adding overflow:hidden to any of the parent containers. Click on the buttons to scrub through the animation: https://jsfiddle.net/r3fokdvm/15/show Clicking on Prev Frame button a couple of times after the elements are visible will correctly show the animation as they exit from the top. Is this some type of weird visual bug or am I missing something?

Hi, I wish it was my browser but I've tested on Firefox/Safari/Chrome and experiencing the same issue. I tried making a version where you can scrub back and forth through the animation by clicking on two buttons but it's still not easy to see the problem in jsFiddle. https://jsfiddle.net/r3fokdvm/14/show Something I did notice is that the elements that are hidden immediately show up if I mess around with any of the style properties that gsap attaches to the element.

I just inspected one of the elements and it looks like once the vertical tween reaches it's end, the element starts animating from the top, off screen, like it's supposed to, but it decides to visually pop in a little after it's on screen. Almost like if it had an opacity 0 assigned to it, I have no idea what is going on. https://imgur.com/a/1eIYWEa Screen Recording 2023-10-24 at 12.47.59 AM.mov

Hi! I did notice the utilities, thanks! I do want them to go from top to bottom but I want the screen to be filled with snowflakes immediately upon page load. I don't think my issue is related to the delay though. I just tried a version of the script where instead of using a delay, I create individual timelines for each element with a paused state, then I set the progress of each timeline using Math.random() and finally play it. This also fills the screen similar to what the delay was doing but I still see issues where some of the dots pop into the screen, it sucks that it's not as obvious from my jsFiddle but I do see it happening even in my fiddle if I stare long enough at it. I'm also attaching a video of how the popping looks. I think it might be related to the fact that it's trying to scroll down a very long container which is several times the height of the window. Could this be somehow related to my issue? https://jsfiddle.net/duwzg2vt/2/show Screen Recording 2023-10-24 at 12.39.03 AM.mov

I made a small reproduction of my current setup, it's hard to tell but some of the elements do eventually pop in out of nowhere: https://jsfiddle.net/a6uoq54e/4/show

I'm trying to understand what the negative delay is doing for the Y based tween in this snowfall codepen. I am currently experiencing an issue that does not make any sense where my implementation, being setup almost identically to this codepen, does this weird thing where using a negative delay causes the looped Y based tween of some of the elements (not all) to start abruptly "on screen" even though it was originally set (using gsap.set) to start somewhere off screen. Removing the delay parameter of the tween unfortunately causes all of the elements to drop down at the same time but they all correctly start off screen. The negative delay is the only thing that helps the animation start with a full screen of snowflakes. I read in a separate post that: "A negative repeat delay will restart it before it finishes." If true, then why does it not happen in the codepen linked where the snowflakes fall perfectly from the top to the bottom of the screen? In my tests some start above the screen but others show up abruptly on screen. This has been driving me crazy 😮‍💨, appreciate any help anyone could provide.

thank you so much @Rodrigo!! I knew there had to be a simpler solution to what I was trying to achieve! I did eventually figure out my original problem, I had to clear out the styles using: $marqueeTxt.style.cssText = ""; I sorta assumed that context.revert() was doing this based on the docs but it wasn't. I'm definitely scrapping everything I just did and using your approach instead, thank you!

Hello! Hi! I am trying to do a text marquee effect that is tied to the scroll position but the only catch is that i need to make sure that the text starts flush and aligned to the left of a grid container and then ends flush and aligned to the right of the container. My primitive dino brain could only think of trying to tween between an absolute positioned left: 0 element to a right: 0 position relative to the container using the flip plugin. I was able to setup this up and it works perfectly but as soon as the browser is resized the numbers are thrown off and the animation stops working. I found a post where they recommend using gsap.context to revert the animations and then restart the flip so it uses numbers based on the new container dimensions. This works perfectly in the demo but I must be doing something wrong when I try to implement the behavior myself because the the animations are killed and the DOM element still keeps the flip related properties with all of it's transforms. If I try to only call context.revert() on window.resize without initializing the flip animation, it will still only kill the animation but keep the flip related properties. Am I missing something? A million thanks for your time and help.

gotcha, i missed the part in the docs where it says that yoyo just repeats the animation in the opposite direction which would make sense why onRepeat is called each time. i blame my lack of knowledge and having to re-read the docs multiple times because i miss things the first couple of times but i figured out a way to do this without using either types of internal checks: const setElementAnimation = function() { setElPosition($el, pos); window.gsap.fromTo($el, { autoAlpha: 0, scale: 0.1, }, { autoAlpha: 1, scale: 1, repeat: 1, duration: 2.4, yoyo: true, transformOrigin: 'center', onComplete: setElementAnimation, }); } setElementAnimation();

@GreenSock sorta, it still requires having to perform that little bit of logic in order to jump over that mental hurdle that onRepeat is being called on both ends of each direction of the yoyo. i thought both directions of the yoyo would be considered a single run. all good though! `this.iteration` definitely helps. i was just thinking if there was something more accessible that could be included in the docs for other people who might get tripped up by this but it's definitely not a big issue. thanks a lot for the super fast response ✌️

@ZachSaucier is using a flag the only way to accurately determine which end of the yoyo you are on? it's so weird to me that onRepeat treats both ends of a yoyo effect as individual runs, at first i thought it was a bug. let yoyoBack = false; gsap.fromTo($el, { autoAlpha: 0, scale: 0.1, }, { autoAlpha: 1, scale: 1, duration: 2.4, repeat: -1, yoyo: true, transformOrigin:"50% 50%", onRepeat: function() { if (yoyoBack) { setElPosition($el, pos) } yoyoBack = !yoyoBack; }, });