Leaderboard

Staggering left and right sounds like you'd want to cycle the x position. Here's a quick example. Hopefully that helps. Happy tweening.

Yeah definitely - if it's inline, it will be erased. The original demo didn't have anything inline so I was assuming stylesheet, but I probably shouldn't assume anything. You got all the extra details covered nicely in your extra demo. Good work.

Ya I just wanted to clarify it will remove any inline CSS(set directly on element from HTML) even if it wasn't set using GSAP, just wanted to avoid any GSAP sucks posts.

In your particular case you could also just call fadeuptl.seek(fadeuptl.duration()) before .kill() so that the animation is moved to the end immediately. I don't know what you're trying to achieve, but another solution could potentially be to toggle a class on the element you're animating, and have !important CSS rules in that class that will take priority over the styles set by GSAP. (Not sure if this is good practice, though.) As a side note, saying a product sucks on that product's support forum, as your very first message, might not be the best way to get help with a particular problem – good thing the GSAP community is extraordinarily nice...

I had made one too

So, instead of GreenSock Guru, we'd just call you Farmer Carl?

Here is how you can get it. The SVG path that you see is only updated externally using retrieved values. In case you don't want to create element. Another method I tried was using modifiers plugin it works but only if both paths have same number of points, I guess while working with svg element @GreenSock does some additional calculations.

I'm not sure what we should be looking for here. The software you're using just demonstrates the fade-in and fade-out animations of the various elements when you select them. Unless I'm mistaken the actual live website wouldn't behave this way, the animations would only be triggered when you ask them to via JS or maybe with something that comes built-in with that software... I can see two things you might be trying to do, please let me know if either is correct (or if they're both wrong): 1) you want animations on several elements, and you want them to loop indefinitely without stopping when you select another element... in this case, you would just set repeat: -1 in the tween's vars, like @Sahil mentioned above. or 2) you want different animations in each element, and you do want each animation to stop when you select another element; in that case you'd need to detect that a different element is being selected with some JS, either with a mouse/pointer event or a focus event, and when that happens you pause() the previous tween (and you can also use seek() to jump to the start or end position), and resume() the new one.

@Sahil - I think the OP is asking about styles that existed in the stylesheet before animation. So, if you set the text to red in the CSS and then animate it to green in the tween, clearProps:"all" will produce red text again. Of course, that may not have been the exact question.

No it will remove all inline CSS properties or the ones that you select to remove, even if you set them from HTML. If you want to just reverse what certain tween did then you can seek it's progress and pause/kill the tween. Also you can simply set repeat property to -1 and it will repeat forever so you don't need to use onComplete callback to restart tween/timeline.

If you edit your first post, you should be able to change the title. Do you have a link to the particular effect you're trying to achieve? Slider Revolution does a whole lot of things, it's hard to understand exactly what you're aiming for and why you would need to remove CSS properties. (Not that you can't do it, as @Sahil and @PointC have said, it's just that you might be taking a suboptimal approach without realising )

Yes - it will only remove CSS related to GSAP. Anything else you've set in your stylesheet will be unaffected. More info in the docs: https://greensock.com/docs/Plugins/CSSPlugin

I'm not sure which property you want to cycle, but you just have a little syntax problem. If you wanted to cycle the x position, you'd write it like this: tl.staggerFrom(items, 2, {autoAlpha: 0,scaleX: 0,scaleY: 0, ease:Bounce.easeOut, cycle:{x:[-100,100]} }, 0.1); Hopefully that helps. Happy tweening.

You can clear props by using clearProps property of a tween but in this particular case you will have to use a set tween inside your click event. clearProps: 'all' is wild card that will remove all inline styles, if you want to remove only few CSS properties then you can pass them as comma separated list. What you are expecting kill function to do is extremely rare case, if GSAP cleared properties when kill() function is called, it will be unexpected behavior for almost all users.

Only thing that can cause that error is if you are loading TweenLite after your custom script.

Great job, guys. Love them. Thanks for choosing relatively flattering body doubles. I have a sense I should delete this thread before @Dipscom gets involved...

That's great Sahil. Always good to see how usable solutions can be seen by another set of eyes. What you did certainly works to mimic the desired effect very well! I just have to say that I've been bitten many times thinking something is so fast that the user can't break it only to find out a client wants to change the timing, and some very strange edge case pops up where users occasionally get the effect to glitch out and it takes hours and hours to figure out and I'm left wishing I had become a farmer

Thank you very much Sahil! Great solutions. For now I'll try to implement something like this: const obj = { d: "M1000,30.1V158H0V0c169.7,238.5,374.3-76,502.6,106.8C615.7,268.2,759.9-15.4,1000,30.1z" } TweenMax.to(obj, 1, { d: "M1000,157v1H0v-1h502.6H1000z", onUpdate: (v) => console.log(obj.d) }) It works great. I have relatively simple shapes to morph so I think I can make some modifications in Illustrator and use d attribute. For more complex paths I will use your first solution. Thanks, have a great day!

Is this along the lines of what you were after I modified your original post. It demonstrates basically how to set up the css and I modified a few of the animation properties so it slides visible items to the left. This is hardcoded to absolute sizes in px. If you want to place it here there or everywhere in a WordPress site then you would have to probably work out percentage based sizing for things to have it work wherever you want to place it.

I am guessing what you want is to slide children around in a parent element and have them be hidden when they are outside of it's frame? The basic css for this is to have the parent set position:relative with overflow:hidden and the children (elements you are sliding) set position:absolute with left,top or x,y positions, and animate them to wherever you want them to go. Note that the parent item will need to have it's size declared or calculated in some way; ie width:some value, height:some value as well, as absolutely positioned children will not impart size to their containing elements. Assuming your script is running properly, getting the right selectors etc, it sounds to me like your issue is probably your css construct.

I'm not sure I'm following your new question. You're saying that everything works correctly in the CodePen demo, but not in your WordPress site? If that's the case, I'd say some other script, plugin or CSS must be causing a conflict. Do you happen to be animating the same divs with CSS and GSAP so they fight for control? Just a guess. As far as the CSS goes -- I would think setting position absolute and top:0 on the divs would certainly place them on top of each other. I wish I could offer more advice, but this sounds like some other conflict not related to GreenSock. If you can recreate a GSAP related problem in your CodePen demo, we can almost certainly help you with a solution. Happy tweening.

Sahil has most likely nailed it if TweenLiteis not defined then it is probably not present when your script initially tries to run. Also if you haven't already you probably want the script inside a document ready or window onload to make sure the all the assets are ready when the script runs.

That's super easy. You just have to speedup ongoing animation so it won't overlap and add delay of 0.1 second to both timelines.

Yes, that is helpful! Thank you all for explaining how to best understand this use of your library.

GreenSock is easy. Understanding how the browser behaves is the hard part, and there is no easy way to learn that. The MDN web docs is the first place I turn to when I need help. https://developer.mozilla.org/en-US/

Shiny new CSS properties. If it's available, let's use it. filter: brightness(90%) contrast(70%) hue-rotate(68deg) saturate(400%) sepia(80%) What could possibly go wrong? Performance all comes down to what you're animating. Replace the hero animation with a canvas animation, and pause/hide stuff that isn't visible, and your site will be usable. All the animations are in the background, so there is no compelling reason to use HTML/CSS. And yes, you can use GSAP to animate canvas. Check out the showcase page. Not every, but most of the sites on that page use canvas/WebGL for background animations. https://greensock.com/examples-showcases

Well, GSAP won't be a magic bullet that'll make that page perform beautifully by simply swapping it in there. In a way, it's a layer of abstraction, but only at the JS level - it doesn't use CSS animations/transitions for anything. So in that respect, it's very different than what you're using right now. I suspect that the bigger problem is the sheer amount of work you're throwing at the browser's rendering engine, repaints, etc. GSAP might help a bit, but it'll likely take some reworking of the structure of the page, how you're setting everything up, the amount of subtle animations you've got going simultaneously, etc. It seemed like you've got a LOT going on, most of it rather subtle but it's costly nonetheless, so you may want to consider sacrificing some effects for performance. The more pixels you're changing (even a tiny shift in color/opacity), the bigger the repaint area and the more work the browser's gotta do. Keep the changes to as small an area as possible. You may even want to consider switching to <canvas> for chunks of it.

That goes for filters too. They are rendered in a multi-step process just like opacity. I noticed a huge boost in performance when animating complicated filters using will-change. .has-texture { will-change: filter; }

Remember this? https://hacks.mozilla.org/2017/10/the-whole-web-at-maximum-fps-how-webrender-gets-rid-of-jank/ That is the best explanation of how browser rendering works. Some people think animating opacity is cheap because it's not destructive, but that's not completely true. It can actually be a rather complicated process. See the part about "Minimizing the number of intermediate textures". So yes, Firefox is most likely optimizing it. The will-change property is extremely difficult to work with when scaling, but it does serve a purpose. .has-texture{ will-change: opacity; }

There would be a few ways to go about using a different ease for play and reverse. Here are a few threads that have good information. https://greensock.com/forums/topic/9229-how-to-apply-different-easing-of-animation-normal-and-reverse/ https://greensock.com/forums/topic/8040-change-easing-for-timeline-reverse/ https://greensock.com/forums/topic/11702-reverse-elastic-ease-in-no-ease-reverse/ If it were me, I'd probably just change the tween ease to Linear and then tween the timeline back and forth on click with the .tweenFromTo() method. You can then use a different ease for each direction. Here's a fork of your pen with that possibility. I just used a Bounce ease so it's really obvious what's happening. Hopefully that helps a bit. Happy tweening.

Thanks again for the suggestions around clearer communication of GSAP's value/capabilities. I can see how it'd save a little effort in that particular use case, but we've always gotta weigh the potential benefits with the costs in terms of performance, file size, and API expansion. Doing something like this means adding a new special property that may have to get checked inside every method that restarts (play(), restart(), resume(), paused(), etc.) but also give folks a way to disable it after the fact (like "I know I set invalidateOnPlay:true, but when the user hits this particular scenario I don't want that to happen, so how do I override that?" kinda thing). Since it's pretty simple to just tuck an invalidate() call wherever you want it (yourTween.invalidate().restart()), I'm struggling to see the potential benefits outweighing the costs. See what I mean? Here's an example: Does that help at all?

oh, it looks like you can animate the opacity of the text's parent:

Hi @mvaneijgen The .add() method does not take parameters. https://greensock.com/docs/TimelineMax/add You'll want to use .call() https://greensock.com/docs/TimelineMax/call() So you'd write it like this: .call(notificationIn, ["#notification__first"], this, "+=.5") Another problem with calling the notificationIn() function a second time on the same element is your scaleOut() function. That function animates to a scale:0, but your notificationIn() function is animating scaleX from 0 to 1. You can fix that by changing the scaleOut() function to use scaleX instead of scale. Hopefully that helps. Happy tweening.

Yep, I believe @Sahil is correct. You're setting the resetDuration to true which is causing the issue in that demo. Once I changed that, it seemed to work (or did I miss something?) You can add a tween to a timeline anytime. It can pick up the animation from wherever you want - it's just a matter of aligning the playhead with the desired location. Remember, you can set a tween's startTime() to whatever you want. So, for example: newParentTimeline.add(tween, newParentTimeline.time() - tween.time()); There are several other options too, but I don't want to overwhelm you And you don't have to specifically remove() it from its old timeline because it can only exist in one place at a time anyway (it'll automatically be removed from the old parent). Does that help?

Yep, it sounds like an onUpdate is your best bet. Querying element.style.opacity is probably no slower than creating another proxy element and animating the values simultaneously and checking that object instead. You're doubling the memory in that case, and adding another set of calculations on each tick. I doubt it'd help much, but you could ONLY do the proxy object thing and then inside your onUpdate, that is where you'd apply it to element.style.opacity (just so that there's only one thing animating, the simple proxy object, and you're merely applying that value to the element in the onUpdate. But again, I kinda doubt you're gonna notice much of an improvement with that strategy. Good luck with your experiment.