GreenSock

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.

It shouldn't cause any problems if the starting values (set in the CSS) are based on ems or rems because the getComputedStyle() values that browsers report are almost always in px anyway. As far as whether or not it would cause inconsistencies in the designs on mobile devices or something, I can't really think of anything that would be problematic but I'd recommend doing some tests and let us know if you run into any issues. We'd be happy to help troubleshoot a codepen example or something.

Sorry about that - I needed to tweak one block of code. It should be resolved in the preview now. https://s3-us-west-2.amazonaws.com/s.cdpn.io/16327/TweenMax-latest-beta.js Better? Blake, if you notice any performance issues, please let me know. Yes, there is a small cost to doing the "display" check on elements when their transforms are being animated but it shouldn't be too bad. It skips the check if it senses that any transforms are applied (so the check only happens when it's "none" or an identity matrix, although granted that's the most common case initially).

From what I can tell, this is unrelated to GSAP - I just removed all the JS code (so GSAP wasn't a factor) and the positioning was off in Safari as you described. It's some issue in your CSS. We try very hard to stay focused on GSAP-specific questions in these forums (we just don't have the resources to provide free consulting for other issues) but hopefully Jonathan's advice proves helpful. He's a gentleman and a scholar

If I understand your question correctly, the problem is simply that you were defining transforms in non-pixel values (ems in your case). You can use "%" or px (the default). There are several reasons for this: Performance The nature of matrices simply won't allow for non-pixel values. We could certainly convert the units into their px-equivalents but that wouldn't be a "true" simulation because for example if you used "vw" and then after the transform was animated to its end value, you resized the window, it wouldn't alter the position. Consistency. We store numeric values in the _gsTransform object which makes it easy for folks to look up the current value at any time, but if we start making that number relative to arbitrary units, it creates an inconsistency and could cause a lot of headaches for folks. In other words, if element._gsTransform.x is 50, does that mean 50px or 50em or 50vw, etc.? If it's always px, that simplifies things quite a bit. Again, the biggest reason has to do with performance - we could apply a bunch of logic to simulate/accommodate other units but it's very rare the developers have requested this over the years and I'd rather not cram all the extra logic in there and force everyone to pay the performance cost.

No, there is no such function, but you could do something like: function shortestRotation(currentAngle, newAngle) { var temp = {rotation:currentAngle}; TweenLite.set(temp, {directionalRotation:{rotation:newAngle + "_short"}}); return temp.rotation; } Then, you can just reuse that function and pass in the current angle and new angle.

Yes, GSAP actually manages the z part of the transformOrigin internally in order to work around a bug in Safari. It's very intentional. But like Dipscom said, it doesn't actually change the way things look - GSAP adjusts the matrix() or matrix3d() values to accommodate the z part of the transformOrigin. If we didn't do it this way, some versions of Safari simply wouldn't animate/render correctly. Again, that was a browser bug that's unrelated to GSAP - we just figured out a way to protect you from it