GreenSock

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

You’ve obviously put a lot of thought into it and have a good understanding of some of the challenges animators face today. I think an IDE/GUI for building GSAP-based animations is an excellent idea…but there are several concerns that make it a less-than-ideal project for us to tackle: We’re very focused on the runtime/scripted engine. Attempting to build a full-fledged GUI is a massive undertaking (well, to do it “right”, the way we’d want it done). We simply don’t have the resources. Building a tool like that takes a very particular skill set. We’ve seen many companies attempt animation GUIs and most have failed. You need an excellent sense of UI design. When a GUI is built by a code-focused developer, it’s very easy to tell. It typically has lots of nifty little nuggets packed into a super crowded UI that nobody (except the author) would ever want to (or know how to) use. Their intentions are always excellent…but UI design is an art form that precious few have. Currently, we’re code-focused and prefer it that way. We don’t want to limit GSAP’s appeal in the wider market by making it seem tethered to our own GUI. The way things are now, many different GUI makers could leverage GSAP. Some have approached us about doing that at some point. We think it’s smarter to leverage their experience with building GUIs, their existing customer base that may already be comfortable with their product, and employ our pervasive technology under the hood for maximum performance, compatibility, and reach (especially on ad networks where GSAP’s file size is exempt). I totally appreciate the suggestions and the passion with which you’ve offered them. Love it! And we resonate with the desire to see an awesome GSAP-based GUI that also allows hardcore coders to work their magic. That’d be amazing. We’ll continue looking for opportunities to help other teams who want to make that dream a reality. Don’t hesitate to offer more suggestions. We’re always looking to improve. Oh, and regarding the path deforming, you should be able to accomplish that sort of thing by placing those extra anchors strategically in your SVG. Building an API that allows per-point animating without becoming overly complex/intimidating/bloated is definitely a challenge. Very few people seem to have the need for this sort of thing anyway, especially given all the work we did on the internals of MorphSVGPlugin to "automagically" find the optimal way to morph between 2 shapes. Usually it "just works" and you don't have to do all the extra work with the other points or defining a shapeIndex, etc. And trust me - there's a lot of logic packed in there to figure it all out

Yep, exactamundo. You had an old plugin. And yes, it should be fine to use the updated plugin with 1.18.0 of GSAP. Go forth and morph to your heart's content.

Oh, and if window.innerHeight changes, you just create a new tween the overwrites the old one (or you could manually kill() it). It's pretty trivial to set up a "resize" listener to trigger that.

Yep, I was thinking the same way PointC was - just use straight JS (like window.innerHeight). I certainly wouldn't consider the lack of tweening "calc()" values in GSAP to be a "bug" because it strikes me as impossible to do. How could it animate between dynamically calculated values? What if it starts at "calc(50px + [window height])" and ends at "calc(-100vh + [nav container height] + [2x nav bottom property])"? There are completely different numbers of properties, units, relative values, etc. Sure, we could apply them at the moment the tween starts and use the calculated values but that's not technically accurate. What if someone resized the window DURING the tween? See what I mean? Perhaps I'm missing something, but I'm pretty sure the only way to do this would be to force the use of computed values at a give time (start of the tween) and live with the fact that they wouldn't be dynamic during the tween at all. In other words, it'd convert to something like "235px to 131px" instead. If it were me, I'd probably just use JS since it's so dynamic by its very nature and avoid CSS calc() values altogether.

You can only morph <path> elements. Kinda makes sense if you think about it because a <circle> couldn't somehow be manipulated to be something other than a circle. Don't worry, though - MorphSVGPlugin has a built-in utility for converting various SVG shapes into native <path> elements, like: MorphSVGPlugin.convertToPath("#yourID"); Check out the docs, including a video: http://greensock.com/docs/#/HTML5/GSAP/Plugins/MorphSVGPlugin/convertToPath/

Nah, you're not missing anything obvious. Don't worry. Plenty of people have probably wondered something similar. But as far as I can tell, there's no benefit to offering the ability to move the starting point on the end shape as well because the whole purpose is to simply figure out how to align the points (in order) between the start and end shapes, and doing so only requires shifting the points in ONE of the paths. Think of it like a combination lock where you have to spin a dial to line a particular number up with the top of the outer ring - even if you could move the outer ring independently, you'd still end up with the numbers around the edges aligning in the same way as they'd be if you only moved the inner dial. That probably doesn't clarify things very well (sorry, I can't think of a better way of explaining it right now), but I guess my point is that I couldn't visualize any matching of points that couldn't be achieved simply by altering the order of points in only the starting shape. Maybe think of it this way - imagine labeling each point on each shape in the order you WANT it to be. So in this case, you said you wanted the circle to start at the TOP instead of the right side. So draw a "1" at the top, and then go around the circle "2", "3", "4". We're not actually changing anything about that path - we're just visualizing what we want. Now label all the points of the starting shape in its native form. I bet the numbers aren't matching up the way you want (if "1" from the start went to "1" of the end). All we need to do is figure out how many places to shift the points on the starting shape so that the "1" labels line up. Done. So even if we never changed the points on the end path, it all boils down to shifting the points in the starting path to line up with the corresponding points in the end shape (and remember, MorphSVGPlugin always adds extra points when necessary to ensure that the starting and ending paths have matching numbers of points). All that being said, maybe it'd help if you explained what effect you feel like you can't get currently and maybe we can help. For example, "I want the tip of the first finger to animate to the top of the circle" (or whatever). Also remember than you can flip the direction of the path by using a negative shapeIndex.

Nobody else has requested it, and we have added hsl() color capabilities (including relative values), so hopefully that will suffice.

Wups, in the ActionScript version progress() is TweenMax-only. Either use that or leverage the time() method like tween.time(tween.duration()); to skip to the end and tween.time(0); to rewind.

Nice job. By the way a quick way to convert a NodeList into an Array is: var list = document.querySelectorAll(".whatever"); //NodeList var ar = [].slice.call(list); //BOOM, returns an array.