GreenSock

Actually, we purposely don't point it at the minified file like that because most people using build tools prefer it that way. It's better for debugging, and they typically have their own minification step in their build process.
 
If you really want the minified file, an easy solution for you would be to simply drop that file into the appropriate directory and rename it (removing the ".min"). Unless I'm misunderstanding. 

You mean all active timelines in the entire application? No. That method is called on a single instance and it'll return all of the active child tweens and/or timelines. GSAP doesn't maintain a list of all of the timelines globally. You can, however, keep an array yourself and then loop through it and check each timeline's isActive() method to determine if it's active. 

Sure, here's an example:
http://codepen.io/GreenSock/pen/zyxgh?editors=101
 
And here's a collection of a bunch of Draggable codepens in case they're helpful:
http://codepen.io/collection/AtuHb/

First of all, thanks for the kind words - it's really nice to hear compliments coming from an ex-Velocity user. And as far as that misleading performance demo on Julian's site, I have to take a good portion of the blame for that because there was a bug in the jQuery plugin for GSAP that would cause things to perform poorly in a very particular scenario which is exactly what Julian's demo was doing. That bug was fixed promptly, and Julian has since removed GSAP from his demo. He has been very nice about it. As far as I can tell, GSAP is at least as fast, and often faster than Velocity. Plus, as you have found, GSAP offers a lot more flexibility and power. But in fairness to Julian, he really wasn't trying to build a tool that's as robust as GSAP - Velocity is more for simple UI animations in the DOM. 
 
Anyway, I peeked at your demo and it looks like Diaco has already provided a solid solution (thanks Diaco!) but I wanted to offer my take on things in case it helps:
http://codepen.io/GreenSock/pen/1cc3cfbad8a99848a5aa9f8927332259/?editors=001
function staggerShake(elements, options) {   options = options || {};   //parse options and defaults   var delay = options.delay || 0,       ease = options.ease || options.easing || Linear.easeNone,       stagger = (options.stagger == null) ? 0.3 : options.stagger || 0,       repeat = options.repeat || 2,       strength = options.strength || 1,       duration = options.duration || 0.1,       //now create the timeline that will house all the animations (we'll return this so you can easily control things or nest it in a master timeline or whatever)       tl = new TimelineLite({delay:delay}),       //based on the strength, determine the number of pixels we should move       distance = strength * 20;   tl.staggerTo(elements, duration, {x:"-=" + (distance / 2), ease:ease}, stagger)     .staggerTo(elements, duration, {x:"+=" + distance, ease:ease, repeat:repeat * 2, yoyo:true}, stagger, duration) //notice we're inserting at a position of "duration" which just means we're starting this stagger sequence right after the first tween is done   .staggerTo(elements, duration, {x:"+=" + (distance / 2), ease:ease}, stagger, duration * (repeat * 2 + 1)); //again, notice we're calculating the proper insertion point here. There are other ways we could do this, like looping through each element and creating a timeline instance for each, and nesting them in a master one in a staggered fashion, but I just liked the simplicity of using three staggerTo() calls and calculating the correct position.   return tl; } $(document).ready(function() {   staggerShake($('h1'), {stagger:0.2, strength:2, duration:0.1, repeat:2, ease:Power1.easeInOut}); }); The nice thing here is that everything is tucked into a nicely configurable staggerShake() function that returns a TimelineLite, thus you have total control of everything. You could tuck that resulting timeline into a master timeline, or tweak the timeScale or pause/resume/reverse or whatever the heck you want. Notice a few other conveniences: 
I added a "strength" option so that you could make things shake more or less wildly. 1 is the default. 2 gives you twice as much movement, etc. I switched from animating "left" to "x" which is the same thing as transform: translateX() because it typically performs better, delivering GPU acceleration and sub-pixel rendering. Feel free to switch back if you prefer.  I added a "duration" option so you can make the animation longer or shorter. Is this what you were looking for? 

Nope, sorry, that's just a browser limitation. Unfortunately, IE8 is just a terribly limited (and slow) browser that Microsoft doesn't even support anymore You might want to consider dropping support for it as well, although I know for some client's that's not feasible. 

That was an issue with Draggable - sorry about that. It should be fixed in the upcoming release. I have attached a preview - please let me know if that works well for you. 
GSAP_1.14.3_preview4.zip

Just to provide a few more details...
 
We use a special version of the plugins on our web site and in our codepen demos. That version will only work on specific web sites. When you load it, it will check the domain and if it's not a "legal" one, it'll redirect you to that page on our site giving you a warning. However, the REAL version of the plugins that come with Club GreenSock memberships do not contain that special code. So when you become a member and use those legit files in the members-only download, you'll never get redirected to our server. We do not install any special "phone home" scripts, and the JavaScript files never communicate with our servers directly for any sort of validation, thus even if greensock.com went down, it would NEVER affect your project. 
 
So again, the key distinction here is that the plugin file you tried using was a special limited version that only works on certain sites (otherwise a lot of people would just steal it and never buy a membership that's required). When you buy the membership, you get the file that has no such limits.
 
Does that clear things up?

Yep, it looks like you just forgot to add the "#" to indicate an ID in your selector text. Very old versions of GSAP allowed that (although we never recommended it), but now that we added querySelectorAll() support (which gives you a LOT more options for selector text without having to load a selector engine like jQuery, saving you kb), it's just not feasible to accommodate that. Trust me: it's a very good upgrade, and well worth the tradeoff for the few people who omitted the "#" previously. 
 
In summary, just add the "#" and you'll be golden

Excerpt from the CSSPlugin docs: 
 
 
Remember, there are dedicated "xPercent" and "yPercent" properties which is actually a very powerful thing because you can COMBINE them with normal px-based x/y translation. 
 
So in your case, you were setting the regular x and y to percentage-based values, so the plugin thought "oh, he's setting a percent value...as a convenience we'll just funnel those values to xPercent and yPercent...", thus x and y ended up being untouched/unanimated. If you want to animate percentage-based values, use the xPercent and yPercent properties and you'll be golden. 

Yep, that was a typo in the docs. The correct way to set it is via TweenLite.defaultEase (which affects TweenMax too). Sorry about that. Should be fixed now. 

The parseColor() function in CSSPlugin accepts just about anything and returns an array with the red, blue, green, and alpha parts, like [255, 102, 51, 0.5]
 
Is that helpful? I'm not 100% sure it's wise to expose it because it kinda locks us into that behavior and expands the API surface area. 

Please snag 0.3.2 now and give that a shot - it should fix all the <br> issues and the faulty words array that was introduced in that [wrong] file yesterday. Again, I apologize for the mix-up. Please let me know if things work well for you now. Oh, and if you want to use it on codepen, this URL should work: https://s3-us-west-2.amazonaws.com/s.cdpn.io/16327/SplitText.min.js

If you're just asking how to make a tween not auto-play, there are two ways:
//just set paused:true in the vars: var t = TweenLite.to(e, 1, {x:100, paused:true}); //or pause() it right away: var t = TweenLite.to(...); t.pause(); The same goes for TimelineLite or TimelineMax instances. You get total control of pretty much every aspect of your animations
 
Does that answer your question? 

We're still finalizing a few things, but I wanted to get you a preview copy of the upcoming release so that you can get your project working. Let me know if this resolves the issue for you. 
GSAP_1.13.3_preview1.zip

Since you're forcing the "left" value to something different inside the onPress, you need to tell the Draggable to update() which essentially re-analyzes that property internally and calibrates itself. Here's the updated codepen: 
http://codepen.io/GreenSock/pen/edf06dac91799e27a975e7de8f8bb0a6/
 
I also noticed some inaccuracies with the way the percentage was being reported (I think that's why you were adding the "limit" thing in there), so I fixed that as well, and avoided the jumpiness that was caused by your Math.floor() of the percentage. It seems to be working smoothly now. 
 
Enjoy!

Can anyone else reproduce this? I downloaded the zip, loaded the file in Safari 7.1, and refreshed over 100 times and couldn't see any problems. If there is a problem, it sure seems like it'd be a Safari thing, not a GSAP thing but it's pretty tough to diagnose without being able to reproduce the problem
 
You are using the latest version of GSAP in all your tests, right? (I'm not aware of any bugs in previous versions that'd cause this problem, but I'm just making sure you've got the latest files). 

There are a few problems:
Draggable.create() returns an Array of Draggable instances (remember, you may pass in selector text that'd match many elements, thus a Draggable would have to be created for each one). You were setting/getting the x/y on the Array rather than the Draggable. For performance reasons, Draggable doesn't have two-way binding with the target, so when you alter the x/y on the Draggable, it doesn't automatically set the actual target's x/y to those values. You mentioned "scroll position" but I assume that was a typo, right? Your Draggable is of type:"x,y", not type:"scroll". The proper way to handle this is to set the x/y on the target of the Draggable itself using TweenLite.set() like:
TweenLite.set(draggable[0].target, {x:100, y:100}); If you want to also force the Draggable's x/y to update so that it reflects your change to the target's x/y, you can either manually call the draggable's update() method, or you could leverage the onUpdate of the tween to do that for you (this is useful if you're actually tweening the target over time):
TweenLite.set(draggable[0].target, {x:100, y:100, onUpdate:draggable[0].update, onUpdateScope:draggable[0]}); console.log(draggable[0].x, draggable[0].y); //100, 100 But that really isn't necessary unless you've got some code that's looking at the Draggable's x/y properties. Those are really meant as an easy reporting tool, like during dragging. Kinda like an alias for the target's true x/y. 
 
Also note that if you want to programmatically set the scroll position of a type:"scroll", you'd need to tap into the special scrollProxy object that Draggable creates which is what handles all the overscolling calculations. So yourDraggable.scrollProxy.scrollTop(100) would set the top scroll position to 100, and yourDraggable.scrollProxy.scrollLeft(100) would set the scrollLeft accordingly. 

Yep, and just to clarify (since you asked about sequencing two steps), it might look like:
var mydiv = new TimelineMax() mydiv.fromTo(".mydiv", 1, {opacity:0, scale:0}, {opacity:1, scale:1})          .to(".mydiv", 1, {opacity:0, scale:2}); I would HIGHLY recommend checking out Carl's outstanding videos/articles about timelines:
http://greensock.com/sequence-video/
http://greensock.com/position-parameter/
http://greensock.com/css-workflow/
 
Seriously, once you get the hang of the syntax and the concept of timelines (which you can nest), you will never want to go back to using CSS animations

Thanks for asking about this. I assume you got a single developer license. Your license covers YOUR work and it doesn't matter if you're doing that work for a client or your employer (which is basically the same thing as a client). So yes, that's totally fine. However, your license would not cover the work of other developers at that company. If your employer wants to give other developers access to the bonus plugins and/or have other developers work on projects that require the special commercial license, that company should get the appropriate multi-developer Business Green membership. Sound fair? 
 
Thanks again for reaching out and asking. We put a lot of faith in our customers to do the right thing and we're thrilled to have guys like you on board. 

The problem had nothing to do with GSAP or it syntax - it was just a problem with your jQuery selector text:
$("wob") //BAD $("#wob") //GOOD You were telling jQuery to literally select all of the <wob> tags instead of the element that had an ID of "wob"

Because "auto" isn't a number, so GSAP doesn't have values to interpolate between. In other words, what's halfway between 10px and "auto"? You could try calculating the number you're looking for using things like offsetLeft and offsetTop.

This has nothing to do with GSAP - your e.offsetX and e.offsetY are undefined in Firefox. This may help: http://stackoverflow.com/a/14872192

We don't really support 3rd party libraries like SuperScrollorama here, but I'll mention several things:
I believe ScrollMagic is the newer, more modern version of SuperScrollorama. You might want to check it out.  This sounds very much like an issue that was reported with ScrollMagic which you can read about extensively here: https://github.com/janpaepke/ScrollMagic/issues/145 As a quick "fix", you could try TweenLite.defaultOverwrite = false; at the beginning of your code to prevent GSAP from doing its automatic overwrite management (usually that's a very valuable feature, but in your case due to the way these scrolling libraries work, it becomes possible to fire overlapping tweens that conflict with each other).  You don't have to wrap your css-related properties in a css:{} object, although it's perfectly acceptable to do it that way. I just wanted to point out that you could consolidate your code quite a bit. You can also pass selector text directly to the tweens - you don't have to wrap them in $(...). 

That kind of functionality isn't built into Draggable, no. You could apply some logic using onPress/onDrag/onThrowUpdate like this:
http://codepen.io/GreenSock/pen/5d3babf9d4a6aa4db2bd7551b8475d7a
 
But it gets more tricky if you're trying to apply bounds too. Not impossible, just more complex. 

It sounds like you may just be misunderstanding what "x" and "y" refer to in the context of the DOM and CSS. Those are for CSS transforms, and map to the "translateX()" and "translateY()" components of the official CSS spec. Think of CSS transforms as always being relative to where that element would normally sit in the flow of the document (with no transforms applied). So in a sense, x and y are like offsets. It sounds like you were expecting them to be absolute measurements from the origin of the parent (kinda like in Flash), but that's not the case. 
 
You could set their position:absolute and their parent's position to relative or absolute so that they're all starting out at the top left of the parent, and use that as if it's the origin to get a consistency. 
 
Does that clear things up at all?