Search the Community

Hello, I'm really excited to get the opportunity to work with gsap! I'm currently having an issue with reusing the same gsap function for multiple elements. My goal is, that each box-container gets triggered individually when they come into the viewport. Currently, the animation function is only applied to the first box-container, which is also the only one that has gotten a scrollTrigger marker applied to it. What I want however, is that each bock-container gets their own markers and is triggered individually. To me, my demo really makes sense but it's obviously not achieving what I need. I would really appreciate if someone could explain to me where I went wrong ^^ Thanks! Edit: I've changed the animations from when I first posted, but I added some comments to the codepen for later viewers that might experience the same problem to see the progression.

Hi there! We (among many others) are trying to fight against issues on CMS platforms (e.g. WordPress) caused by loading multiple versions of GSAP. We've already examined previous threads about possible solutions: http://greensock.com/forums/topic/7753-two-versions-of-tweenmax-on-same-page/ http://greensock.com/forums/topic/7074-jquery-wrapper-animate-stop/#entry26398 http://greensock.com/forums/topic/9881-avoid-multiple-loaded-tweenmax-and-tweenlite/ http://greensock.com/forums/topic/9910-order-loading-tweenmax-and-tweenlite-error/ However, none of the mentioned suggestions give us a perfect solution to avoid conflicts. In an environment like WordPress, we cannot control the script order / GSAP builds & versions for every plugin and theme. If there would be 10 entirely different versions, then we would have to deal with that, without the ability to change scripts from other parties. We're following this topic for years now, hoping that a perfect solution would come one day. Sandboxing does not seem to be reliable in all cases, often times we literally replace a conflicting plugin to another conflicting plugin. This occasionally involves angry authors who don't want to accept our reasoning and blame us breaking their plugin without realizing what's going on. I understand that the suggestions you've made to others can help in certain scenarios, but in my understanding it cannot be used as a universal way to avoid issues and not to cause conflicts to others. To this end, I would greatly appreciate if you could answer the following questions: 1. Can you please confirm if this really is the case, so we have some level of proof for other authors? 2. Do you consider handling cases like this internally in a future versions of GSAP? 3. Merging your suggestions from the different threads, I believe we've found the best possible combination. Can you please review the code below and tell us if it is safe to use for us and anybody else on a crowded CMS platform like WordPress? <!-- Loaded by other plugins --> <script src="TweenMax.js"></script> <script> // Store GreenSock vars to restore them later var oldGS = window.GreenSockGlobals; var oldGSQueue = window._gsQueue; var oldGSDefine = window._gsDefine; // Reset _gsDefine to load the new version in all cases // Seems to be necessary for maximize the efficiency window._gsDefine = null; delete( window._gsDefine ); // Capture and separate the new version in the GSAP variable var GSAP = window.GreenSockGlobals = {}; </script> <!-- Our version --> <script src="js/TweenMax.js"></script> <script> // Reset everything window.GreenSockGlobals = null; window._gsQueue = null; window._gsDefine = null; delete( window.GreenSockGlobals ); delete( window._gsQueue ); delete( window._gsDefine ); // Restore the affected variables from older version (if any) window.GreenSockGlobals = oldGS; window._gsQueue = oldGSQueue; window._gsDefine = oldGSDefine; </script> <!-- Loaded by other plugins --> <script src="TweenMax.js"></script> Thank you very much for your time and effort! Cheers, George