GreenSock

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

For the record, you could apply the rotation in an onUpdate callback and base it on the previous location. Here's a relatively simplistic way: http://codepen.io/anon/pen/VagEvd var logo=document.getElementById("logo"), prevX = 0, prevY = 0, RAD2DEG = 180 / Math.PI; TweenMax.to(logo,4,{physics2D:{velocity:300, angle:-60, gravity:100}, onUpdate:autoRotate}); function autoRotate() { var x = logo._gsTransform.x, y = logo._gsTransform.y, angle = Math.atan2(y - prevY, x - prevX) * RAD2DEG; TweenLite.set(logo, {rotation:angle}); prevX = x; prevY = y; }

Sorry, Praney, at this point we're not sure we'll release that tool at all. It's a pretty serious undertaking, especially from a support standpoint, and I'm not sure demand would be super high for it anyway. It's definitely a lifesaver in certain circumstances, but I worry that it's a little too geeky for most. We're focusing our resources on other things that would be more likely to appeal to more of our customers.

It sounds like you just forgot to load the ScrollToPlugin file. Make sure that's loaded and you'll be good-to-go. <script src="https://cdnjs.cloudflare.com/ajax/libs/gsap/1.18.4/plugins/ScrollToPlugin.min.js"></script> Oh, and you nested the ease incorrectly - that should go outside the scrollTo object. TweenLite.to(window, 0.5, {scrollTo:{y:topPos}, ease:Power2.easeInOut});

The only time you need that special license is if you're using GreenSock tools inside a site/app/product/game for which you're charging a fee from multiple customers. But if you're merely using it in a site where you happen to sell OTHER products (that don't directly use GreenSock in themselves), that qualifies under the standard "no charge" license. For example, if Nike uses GSAP in their site where they sell shoes (but anyone can use the site itself and it's not a membership-only site or something), that's totally fine - no special license is required. Does that answer your question? Even if you do need the license for your particular project (and I bet you don't), typically our customers tell us that the license pays for itself VERY quickly when you consider the time it'll save you, increased capabilities and performance, etc. If it doesn't or you're unhappy for any reason, we'll gladly refund your money - we are passionate about having happy customers around here (as you can hopefully tell by poking around these forums). Happy tweening!

Thanks for the suggestions, Rob. Sounds almost like a cascading way of defining properties. Ha. "Cascading GreenSock" (CGS) instead of CSS.

Sounds unrelated to GSAP, but I'm curious if adding this line of code to the beginning of your project has any effect: CSSPlugin.defaultForce3D = false; Basically that will make GSAP skip the automatic GPU-acceleration on transforms. If there's a GPU issue on your end, this may resolve things (like if Chrome has to use a software renderer instead of hardware). It's slower, but perhaps it'll get rid of the issue. And again, that's not really a GSAP issue anyway - it just has to do with the browser rendering 2D vs. 3D transforms.

I didn't notice any problems, but it sounds like just a rendering issue that is unrelated to GSAP. Remember, the more pixels you change on the screen, the harder you push the browser's graphics rendering routines (thus CPU/GPU load). If you're only changing opacity, it should be pretty fast though. I'm curious why you're using an onUpdate to change the scaleX of the progress bar rather than simply tweening that value directly. That'd certainly be more efficient, but I doubt this is the source of your "jerkiness" problems anyway.

Sure, a timeline is just a container for tweens. There isn't really a down side to wrapping your tweens in a timeline other than a very very slight performance degradation only because there's an extra function call during each render (I can't imagine you'd notice any difference unless maybe you're running tens of thousands of tweens simultaneously...but even then you may not notice). Totally up to you. And of course timelines can be slightly more verbose to create initially. Again, minor point. I'd say use whatever "feels" best to you from a stylistic standpoint.

I'm not sure I'd say "best" in every case, but yes, autoAlpha has the added benefit of toggling visibility when it makes sense. There's a very slight performance hit during the tween due to the fact that it has to control that additional property but it's pretty negligible. From a rendering standpoint, it is definitely cheaper for the browser if visibility is set to hidden.

By the way, I did figure out a way to just check for "display:none" in a relatively cheap way and work around the browser bug/annoyance internally, so I think your concern will be addressed in the upcoming release which you can preview (uncompressed) here: https://s3-us-west-2.amazonaws.com/s.cdpn.io/16327/TweenMax-latest-beta.js - better?

Not a dumb question - alpha is simply an alias for opacity. No difference whatsoever. It was added originally to help consistency with the Flash API (Flash always used "alpha"). There were a lot of GSAP users coming from the Flash world at the time

The direction of the path is dictated by the SVG data itself. But if you don't want (or don't know how) to correct that, you could still just tweak your tween so that it's going backwards How's this?: http://codepen.io/anon/pen/MyZeoZ

Ah, I see the issue - it has to do with the fact that Draggable aims to stay out of the way of native touch scrolling by default. Since your Draggable is only set to allow horizontal dragging, imagine what would happen if the user tried scrolling the PAGE up and down vertically (pressing on that Draggable element and moving up/down). See the issue? I don't see an easy way to work around that in a totally automatic fashion (a lot of this has to do with discerning user and developer intention which sometimes gets really tricky). The easy fix in this case is to just set allowNativeTouchScrolling:false on your Draggable. Done Better?

Absolutely, you're welcome to release an example. We encourage that sort of thing. The only thing we ask is that you make mention of the fact that GSAP is subject to its own license which is located at https://greensock.com/standard-license/, and maybe encourage them to get GSAP from our own repo or web site just so that they have the latest and greatest version. You don't have to talk about pricing or anything like that. Oh, and of course please don't include any of the members-only plugins in your open source repo Good luck with the project!

Please help us gauge if it would be worthwhile to get more involved with creating some products / services for banner developers. Perhaps that would be templates, videos, podcast new tools for fancy effects…we're not sure. Our goal is to better understand the needs out there and see if we can address the pain points, perhaps with a partner of ours who has a ton of knowledge in the banner ad space. http://goo.gl/forms/2ZZ3c3vzRt Please take a few minutes and fill it out; be as brutally honest as possible. If you want to chime in with other ideas that aren't mentioned, that's totally fine too (drop them in this thread below or in the survey itself). Thanks!

lockAxis is supposed to just be a boolean (true or false) and it's only useful if you've got a Draggable that can move on multiple axis. Try just removing that - does that fix things for you? If not, it'd be super helpful to see a reduced test case in codepen just so we can see exactly what's going on.

You could do something like this: function tween(target, duration, vars) { var tl = new TimelineLite({delay:vars.delay || 0}), copy = {}, p; for (p in vars) { if (p === "position" || p === "scale") { tl.to(target[p], duration, {endArray:vars[p], ease:vars.ease}, 0); } else if (p !== "delay") { copy[p] = vars[p]; } } return tl.to(target, duration, copy, 0); } That way, you can just call tween() kinda like a regular TweenLite.to(), and it'll spit back a TimelineLite that acts exactly the way you want, and is totally controllable. Just a thought.

Thanks for the detailed info (as usual), Blake. You said that we probably don't need that "TweenLite" dependency in there, but wouldn't that cause problems if I removed it because then people couldn't just "require" something like CSSPlugin (or whatever)? It'd break because TweenLite wouldn't be there. I'm curious why that dependency is causing any problems at all, except for SplitText which doesn't really require it anyway. Is it because it assumes a particular directory structure? Are you saying you think it's wisest to just remove the dependencies altogether?