GreenSock

Another technique you could use is with a label: tl.addLabel("dots", 2) .to(".dot1", 0.3, {x:"+=150"},"dots") .to(".dot2", 0.3, {y:"+=150"},"dots+=0.2") .to(".dot3", 0.3, {rotation:"+=150"},"dots+=0.7") .to(".dot4", 0.3, {alpha:0},"dots+=6.2"); I personally prefer Carl's technique with splitting things up into child timelines just because it makes things so modular and easy to create functions that spit back animations that can be nested however/wherever you want. Some people prefer using labels, though. Totally up to you.

Yep

Working well for you?

I'm not at all familiar with Ionic 2, no. Sorry. But I cannot imagine how or why it would be a problem to use GSAP with it because GSAP doesn't care about the rendering layer - it just changes properties over time. Literally, like any properties. Anything JavaScript can touch, GSAP can animate. It was specifically designed to be rendering-layer-agnostic so that once you learn GSAP, you should be able to use it pretty much anywhere, with any framework (or no framework). Let us know if you run into any trouble, though. If anyone here knows about Ionic, my guess would be OSUblake (he's our resident Angular expert too)

Yep, Blake did a great job summarizing things. I'd guess that 95% of the time when someone is running into a performance problem, it has nothing to do with the animation engine itself - it's almost always the graphics rendering load that the browser is struggling with. For example, it may take 1 millisecond for GSAP to set the value of a filter (or any property), but it might take 200ms for the browser to do its work under the hood to calculate all the changes to the pixels on the screen and do the rendering. SVGs are particularly performance-sensitive because of their resolution-independent nature. The browser basically has to fabricate all the pixels on-the-fly (it can't just use the GPU to stretch/scale/shift a set of raster pixels around). I love SVG, and it can be fantastic for many things, but you just have to be careful performance-wise. As for specific tips with GSAP, we've already done a bunch of work to make sure you don't have to worry about much. It's a deep topic, but for most people the main thing to keep in mind is just which properties they choose to animate (which actually has very little to do with GSAP - it's about being mindful of which properties are more expensive for the browser rendering-wise). So stick with transforms and opacity, like Blake said, as much as possible. Great job on the crab(s). Congrats on getting noticed on codepen too Happy tweening!

There are many ways to do it, but here's the most concise: tl.staggerTo([".dot1", ".dot2", ".dot3", ".dot4"], 0.3, {x:"+=150"}, 0.2, "-=2");

Glad you figured it out. Let us know if you need anything else.

The simplest way would involve a TimelineMax with a TweenMax in it: var tl = new TimelineMax({repeat:-1}); tl.to("#box", 2, {x: 400, yoyo:true, repeat:1, repeatDelay:1}); Or, if you're limited to loading TweenLite, you could do it with some logic and a delayedCall(): TweenLite.to("#box", 2, {x:400, onComplete:onComplete, onReverseComplete:onReverseComplete}); function onReverseComplete() { this.play(); } function onComplete() { var tween = this; TweenLite.delayedCall(1, function() { tween.reverse(); }); } Or an alternate with only one function: TweenLite.to("#box", 2, {x:400, onComplete:onComplete, onReverseComplete:onComplete}); function onComplete() { var tween = this; if (tween.reversed()) { tween.play(); } else { TweenLite.delayedCall(1, function() { tween.reverse(); }); } }

Yep, {self} would be a reference to the tween instance itself (not the target). That's why you had to add ".target" to it, to reference the tween's target (the DOM node in this case) Another way you could do this is with another staggerTo() call instead of callbacks. You just delay those tweens a bit so that they line up where you want. This way, all the animation is inside a single timeline instance that you can easily seek(), reverse(), timeScale() or anything like that: http://codepen.io/anon/pen/aNgRWz?editors=0010 Notice I created some variables at the top that you can play with for the timing of all the staggers, durations, etc. Happy tweening!

Draggable has a static hitTest() method that you can just feed two elements into, but beware that it simply uses the bounding boxes to measure overlaps, so it's not literally pixel-perfect for rotated or oddly-shaped things (that'd be a lot more processor-intensive). For example: //simple overlap test if (Draggable.hitTest(element1, element2)) { //do stuff } You can also check that a certain amount or percentage of the elements overlap. See the docs: http://greensock.com/docs/#/HTML5/GSAP/Utils/Draggable/hitTest/

An easier workaround would be to simply call TweenLite.ticker.wake() first (no need to add a dummy listener). But yes, I see what you mean and it should be fixed in the upcoming 1.18.5 release which you can preview [uncompressed] here: https://s3-us-west-2.amazonaws.com/s.cdpn.io/16327/TweenMax-latest-beta.js

Excellent, glad you figured it out. Thanks for letting us know. Sorry you had to bloody your head over this

It's pretty difficult to troubleshoot blind (without a reduced test case codepen or jsfiddle), but I'm guessing this has something to do with the fact that from() tweens render immediately by default and of course they use the *current* values as the destination ("to") ones. Thus, if you create multiple from() tweens on the same element, you'll run into a logic problem (not a bug in GSAP). For example, let's take something super simple: var obj = {x:0}; //obj.x starts at 0 TweenLite.from(obj, 1, {x:100}); //immediately makes obj.x 100, and records the current value (0) as the destination. TweenLite.from(obj, 1, {x:100}); //immediately makes obj.x 100, and records the current value...100 because of the previous line...as the destination. So when you run this code, you'll just see obj.x sit at 100 and never animate. That's exactly what it's logically supposed to do (no GSAP bug), but the author might be confused thinking "wait, shouldn't obj.x go from 100 to 0?" from() tweens can be pretty useful, but they can also be a source of confusion in cases like this. You might have better luck if you use fromTo() tweens, or just to() tweens just because people generally think in those terms better. The whole "use the current value as the destination value" can cause logic hiccups like this. Another option is to set immediateRender:false on your from tweens, but the risk there is that you'll see a brief flash of the original values until the next tick. That could be mitigated by calling TweenLite.render() after you've run all your logic and you've got things set up the way you want. But frankly, I think you might find it easier to work with fromTo() or to() tweens. A 3rd option is to force your timeline to completion before killing it, assuming you've only got "from" tweens in there (solely for the purpose of making the elements return to their original positions). Does that help at all?

If I understand your question correctly, this has nothing to do with GSAP. IE uses a different default way of scaling things. You can probably just tweak your CSS and/or the width/height attributes to normalize things. A quick Google search got me here: http://tympanus.net/codrops/2014/08/19/making-svgs-responsive-with-css/ and https://css-tricks.com/scale-svg/. Sara Soueidan, for example, suggests explicitly setting the width to 100%. Does that help?

Welcome to the forums. I took a peek at your codepen and I think you might be misunderstanding a few things: 1) When you select something with jQuery, it's not really a constantly-updating "live" selection. For example, $(".open") will grab whatever elements have the "open" class at that particular moment (when that call is executed), but then if you add the "open" class to some other element later, it doesn't suddenly update your $open variable to contain that new element as part of the selection. That's just how jQuery and pretty much all selector engines that I know of work. 2) You had a typo in your code - you had $(search) instead of $search (or $("#search") would work too). 3) You were executing your tween immediately (before any click and before anything had an "open" class). It seems like maybe you assumed that somehow the tween would sit and wait and get activated as soon as something had the "open" class applied to it, but that's not how things work. You can easily get that effect, though, with the right code of course. But keep in mind that by default tweens begin running immediately unless you pause them. So in your case, the tween ran on an empty jQuery object (because nothing had the "open" class applied when the tween was created). Then, onclick, you toggled the class but never actually created a tween for that freshly-adorned "open" element. You can just move your tween code into that block to solve this. I also assume you wanted to animate the "y" back to 0% when the class was toggled off. You had no code for that either. So here's my [somewhat more verbose for educational purposes] forked codepen that shows what I assume you wanted: http://codepen.io/anon/pen/qZzpmv Better?

Nice work

Yep, I assume it'd be as simple as recording the rule.cssText and then re-applying that whenever you want to revert. var original = rule.cssText; //then do stuff...(like tweens) //then to revert... rule.cssText = original;

That is pretty weird indeed. Never heard of anything like that before. I looked at the code too and can't figure out why in the world an error like that could possibly get thrown. [scratching head] Can you provide detailed instructions about how to reproduce the issue (including what needs to be installed, where, etc.)? I don't use bower nor webpack, so I may need some hand-holding. By the way, TweenMax is considered the "main" file for the "gsap" package, not TweenLite. That probably has nothing to do with these errors though.

It looks like the problem is that you're targeting an entirely different (invisible) element with your Draggable, but using ".handle" as the trigger. That's fine, but then you set up your code so that you're animating just ".handle" initially, thus its "x" might be 165 but the actual target of the Draggable is still at 0. Your code is using "this.x" to calculate things, and "this.x" refers to your invisible div. Perhaps you were under the impression that the trigger's x would always be identical to the target's x, but that's not the case. I'm curious why you didn't choose to just target ".handle" with your Draggable. It's fine if you don't - I just wasn't sure why. There are quite a few ways to solve this. One would be like this: http://codepen.io/anon/pen/JXQooe?editors=0010 Does that work the way you want?

Welcome to the community! It's tough to say without seeing things in context (like in a codepen), but I'd venture to guess that you can simply shift your variable declarations into your function so that it waits to calculate the footer.offsetTop until gotoFooter() is actually called. There are other ways to handle it, so if this doesn't help, please just provide a simple codepen demo and we'll do our best to provide an alternate solution.

clearProps isn't about clearing only the properties that a specific GSAP plugin affected (GSAP doesn't keep a centralized record of those things...that could cause memory problems) - it's just about clearing whatever inline styles you want. So if you say "all", it'll clear all the inline styles. For CSSRulePlugin, that's not really a thing but you have 2 options that I can think of: If you want to clear all the styles in that rule, you can simply set the rule's cssText to "". Like yourRule.cssText = ""; If you want to revert only the changes that a particular tween made, you could just jump back to the beginning of that tween, like: ver tween = TweenLite.to(..., {cssRule:{...}}); //then later... tween.pause(0); //rewinds to the beginning and stops (reverts changes made by this tween) Does that help?

By the way, I strongly recommend avoiding the "transform" value itself and instead use GSAP's shortcuts like x, y, scaleX, scaleY, rotation, etc. because they're faster and more accurate when you've got rotational values that exceed 180 degrees. When you use "transform", GSAP must apply that to the element, then read back the computed style so that the browser mushes it all into a matrix() or matrix3d() which GSAP must then parse. This is because "transform" values can be infinitely long, chained values. In order to maximize accuracy, it must allow the browser to parse through the whole string and calculate the matrix values and then GSAP extracts the component data. If you just set the individual compenent(s) directly, it can skip all that. Not the end of the world; you'd probably only notice the performance difference in extreme situations where you're asking it to parse hundreds or thousands of values on one frame, but I'm a performance nut.

Hilarious, guys. Love it. Carl's assumption was correct. No, not about the rudimentary phonics engine (though I'm gonna write that one down on the list of potential future upgrades), but the fact that an invalid value applied to a transform will basically just get ignored by the browser, and make it a "normal" (identity) matrix. In other words, try applying transform:skayle(1) directly in CSS and watch what the browser does. The parser will be like "Dude, that ain't valid. I'm ignoring that and assuming you want 'none'" which happens to be a scale of 1. The reason the set() made things "work" was simply because it set an initial value of scale to a non-normal value (0 in this case), so when you tried applying transform:skayle(1), GSAP fed that to the browser and read back the computed style which reported as matrix(1,0,0,1,0,0) which is the same as none which is the same as scaleX:1 and scaleY:1, thus it animated from scaleX:0 to scaleX:1. Make sense now?

No, there is no such callback but I'm very curious why you'd want that sort of thing. Can you explain? Maybe there's another solution. Offering a callback like that inside GSAP for every tween individually would have a pretty bad impact on performance. If you want to call a function before the GSAP engine runs all its updates (on everything for that tick), you could do something like: TweenLite.ticker.addEventListener("tick", yourFunction, this, false, 1); //notice the last number, 1. That's the priority. The core GSAP ticker uses a priority of 0, thus this would get called before that. See the docs at http://greensock.com/docs/#/HTML5/GSAP/TweenLite/ticker/

You have my deepest sympathies regarding having to support IE8. Ouch. It's very tough to diagnose this without seeing it in context. Do you have a reduced test case in a codepen or jsfiddle you could share? That'd be super helpful. Otherwise we're kinda flying blind. You don't need to share your actual project - just a simplified case in a bare-bones codepen or something. Feel free to fork one of our demos like http://codepen.io/GreenSock/pen/irzvd