GreenSock

I might be missing something, but wouldn't it be as easy as tl.timeline? Remember, every animation has a parent "timeline" (well, except the root timelines) and you can access that via the "timeline" property (that's read-only). So in your pseudo code, it would look like: //OLD: var master = tl.getParent(); //BAD if (!master == masterTL) { masterTL.add(tl); } //NEW: var master = tl.timeline; //GOOD if (!master == masterTL) { masterTL.add(tl); }

Yep, ohem got it exactly right. TweenLite is essential for all of GSAP (TweenLite is included inside of TweenMax). It would be a little bit like loading a jQuery plugin and expecting it to work without ever loading jQuery. Sorry if that was unclear in the docs or videos on our site. You pretty much have to load either TweenLite or TweenMax, and then whatever else you want/need. As ohem pointed out, you might just want to load TweenMax because even though it is a bit larger overall, when you factor in all the caching out there and the fact that you get all those goodies in one file (including the timeline classes and CSSPlugin), the real-world performance difference probably isn't even noticeable. This might be worth reading (even if you're not using it for banner ads): http://greensock.com/kilobyte-conundrum/ Oh, and TweenMax isn't 108kb. I assume you were looking at the non-gzipped size, right? Almost all servers gzip things, so TweenMax is actually closer to 35kb. Very reasonable these days. And on every major ad network, it's almost always free (doesn't count against your file size). Happy tweening!

Thanks for helping to spread the word about GSAP. I also appreciate your sensitivity with the bonus plugins and not sharing them in your github repo. It's so nice to have customers like you who respect the work of other developers. It's totally up to you, but I'd probably lean slightly toward option #1 as it keeps the fidelity to what you originally created and demonstrates the "real" code that accomplished what you were showcasing. Option #2 seems kinda like "look what these tools can do!...but I'll rework it in a less elegant, more verbose way and share that version with you" Actually, a 3rd option (my favorite) would be to share codepen versions of your demo(s) that use the codepen-specific bonus plugins (which only work on codepen). The URLs for those can be found here: http://codepen.io/GreenSock/pen/OPqpRJ. That way, they can see everything working and inspect the code and even play with it live in the browser. Gotta love codepen. Thanks again for the sensitivity. Lookin' forward to seeing your English version of the talk on YouTube. Please swing back here and share it when it's ready. Happy tweening!

Great info, Blake. Super helpful. Love the links. I'm not nearly as familiar with Catmull-Roms and I'm a little worried about the costs (complexity-wise and kb-wise) of supporting both Cubic Beziers and Catmull-Roms, but can you confirm that Catmull-Roms would allow you to easily create corner anchors like the ones necessary for "Bounce" eases (where there's **not** a smooth transition)? I totally agree about the necessity for a proper in-browser editor for this type of thing. I don't think, however, that the "it might be hard to fit the handles into the viewport" thing with Cubic Beziers means that Catmull-Rom support is necessary; If the user is allowed to zoom in/out and drag the work area around, it could pretty easily solve that issue with Cubic Beziers. Oh and as for the adaptive question, I'm not 100% sure yet. I'd need to do some experimentation and benchmarking. If you've got strong preferences and research to back it up, I'd love to hear them. But to be clear, this is not something I'm planning to dig into yet...there are several more pressing things I need to work on in the codebase but as I said earlier, I'm chomping at the bit to get to work on this. It's quite painful not to be able to yet

Welcome! Nice to hear from a long-time user. It looks like the problem is twofold: "offset" is an attribute. Thus, you need to use the AttrPlugin The cycling doesn't work in a nested fashion, like inside the AttrPlugin. But that's easy to work around (see demo below) Here's a forked version that seems to work. I just use a function-based value to spit back the appropriate value. http://codepen.io/anon/pen/EypANW?editors=0010 Does that help?

We're moving toward a more full ES6 implementation but that's a very large task. In the mean time, though, you should totally be able to use GSAP in your Browserify/Webpack/RequireJS project. It has hooks in it that should work for all of those. So you can import the classes directly (paths), or you can use the ES6-friendly import statements for anything that's included in TweenMax, like: import { TweenLite, Elastic, CSSPlugin, TimelineLite } from "gsap"; And of course with NPM, you just "npm install gsap" Does that help?

Unfortunately it's much harder to dig through almost 1000 lines of code and try to isolate the issue on a remote server like that. I know it can be a bit of a chore, but creating a reduced test case in codepen or jsfiddle can actually be a great practice that might expose the issue without even needing input from us. If not, at least there will be a codepen that we can tinker with and see exactly what's going on. It's not abnormal for the liveSnap to run several times. Long story. But I definitely would recommend that you not write code that only works if liveSnap only runs once. Also please make sure you're using the latest Draggable version.

Fair point - I just added a note to the 1.19.0 page that specifically mentions that ModifiersPlugin is not included inside TweenMax. Thanks for bringing that to our attention.

Like Jonathan, I'm a bit confused by the question. Do you mean that if you drag left, you want it to move right, etc.? If so, no, there's no specific setting for that but you could code something up by using an invisible proxy element as the Draggable, and then use an onDrag to apply whatever logic you want and move something else.

As far as I know, Safari is the only browser that will render elements in a way that intersects the planes. So imagine two pieces of paper, one laying on top of the other one, and then you take the top one and rotate it on its x-axis - Safari would make half of it go behind the paper it was sitting on top of, chopping it off visually. An argument could be made that this is more "correct", but it's just annoying for a lot of web developers. It sounds like you're running into that issue. Perhaps try offsetting the element's "z" (or "translateZ" in some tools), kinda like picking up that piece of paper and making it float above the other one enough to not have them intersect when the rotation occurs.

I have several ideas that have been bouncing around my head regarding this, but I don't have the bandwidth to dive into it yet. I'm totally chomping at the bit though. I hate responsibilities Performance-wise, yes, it's essential that this thing be blazing fast because the ease gets calculated for every tween, on every render. The fewer the calculations, the better (duh). Quadratic is "better" in that sense, but I personally wouldn't use that because it's too limiting (Cubic is far better for authoring). A single Bezier isn't necessarily terrible, but my goal is to allow unlimited anchors and control points, so it becomes important to be able to quickly isolate which segment is pertinent at the given linear progress value. Again, I have some ideas that I want to sketch out and benchmark when I'm ready. One idea is to turn everything linear and approximate things and allow the end user to set the precision value (how many segments it's broken down into). The path.getPointAtLength() worries me a bit both from a performance standpoint and because it doesn't really map properly to the time/progress data. It gives a certain effect, but it ain't accurate. It could be WAY off in fact (imagine a curve that has huge vertical waves that are packed tightly together horizontally at the beginning, and then halfway through it steadies out to a straight line to the end). Like Blake said, a big piece of this challenge is just making sure there's a solid curve editor in the browser (SVG). If you want to tackle that so people can interactively build a curve, that'd be awesome and likely accelerate the time frame for this kind of feature. Oh, and you can't just divide the progress by the number of segments to find which one is the current one, as some of the segments may be much longer than others. And the editor should probably prevent folks from overlapping anchors on the x-axis. Does someone have a pressing need for this right now that can't be accomplished with any of the other eases or even Blake's tool?

Just for the record, the reason that "dummy" set() call didn't do anything was because you called TweenMax.set() instead of mainTimeline.set(). In other words, you didn't add the dummy tween/set to your timeline Don't worry, it happens to us all.

The shiftChildren() thing could totally work. If it were me, though, I'd probably wrap those particular child tweens in their own timeline, and place that timeline onto your original timeline (nest them). Then, you can easily move that whole chunk around wherever you want using its startTime(). For example, let's say you want them to have an initial delay of 1 second (pseudo code): var master = new TimelineLite(); var child = new TimelineLite(); child.to(...).to(...); //add whatever tweens you want, however you want. //the next line is the key - you just place it into the master where you want (1 second in this case) master.add(child, 1); console.log(child.startTime()); //"1" //then later, if you want to shift it so that it acts like it starts at 2 seconds... child.startTime(2); You could, of course, do that to each of your tweens instead of wrapping them in a timeline but I just think it's a lot more convenient to leverage the power of nested timelines for total control. It's kinda the whole point of timelines (allowing you to group things intuitively) If you haven't read/watched these already, I'd highly recommend them: http://greensock.com/sequence-video http://greensock.com/position-parameter Happy tweening!

Your range is actually 200 (because that's the distance between -100 and 100). So the way you wrote your random functions would always return a value between 0 and 100 instead of -100 to 100. Just change -100 to -200 in your function and you'll be golden: //OLD: Math.floor(Math.random() * -100) + 100; //NEW: Math.floor(Math.random() * -200) + 100; Does that help?

Excellent work, Pete. Thanks for sharing!

Are you saying that the codepen you provided does NOT work? I looked at it in Safari and it seemed identical to what I saw in Chrome. Am I missing something?

Thanks for reporting back about the solution you found to your own question. Good job

Have you thought about just doing a bezier tween to various values? We do have CustomEase on the roadmap for the future, but there are some other things that have been more pressing.

If I understand your goal correctly, all you need to do is alter the stagger and use the position parameter... The stagger would be 1.5 because that's how long it takes for each of your 3-step animations to finish (3 x 0.5) The position parameter just tells it where to start putting them into the timeline. So the first stagger would start at 0 of course, the second batch would start at 0.5 (because that's when the first tween would be done), and the final position parameter would be 1 (because that's when the first 2 tweens would be done). tl.staggerFromTo(".box", 0.5, {opacity: 0}, {opacity: 1}, 1.5) .staggerTo(".box .cover", 0.5, { cycle: { xPercent: [-101, 101] } }, 1.5, 0.5) .staggerTo(".box", 0.5, {opacity: 0}, 1.5, 1); Is that what you were looking for? Rodrigo's solutions are all totally valid too of course.

Thanks for sharing the insights, @Robert. Very helpful indeed.

Oh, and just to be clear, please don't include any of the members-only plugins in a github project that's listed as an open source project because obviously that'd make it way too easy for folks to get the plugin for free and maybe even misunderstand the license (like if it's in an open-source MIT-licensed github project, plenty of people would just assume that means MorphSVGPlugin is also free and MIT-licensed which it's not). Fair enough?

Yep, like Rodrigo said, we totally appreciate folks like you who care enough to try to protect the members-only files but we also realize that this is the web and anybody can view JS so it's not realistic to expect to be able to fully protect things. Our whole business model relies on trusting our users and that most people will do the right thing when given the option. Sure, some people will rip off the plugins but we're not interested in spending lots of resources chasing them down, implementing complex strategies to stop them, etc. We'd rather just keep working on the tools and serving our customers as best we can, trusting that the respect we extend to people will ultimately be reciprocated. Thus far, it's working out pretty well (thanks to people like you). Happy tweening!

To clarify, I didn't mean to imply that the caching benefit is limited to banner ad developers. There are tons of sites linking to our CDNJS files, thus you can just point at those and tap into the caching benefit immediately. If you prefer to just include all the JS in your own payload, that's totally fine too (but as you indicated, you wouldn't get the caching benefits, that's all). Yes, the "oh shoot, I forgot to load that plugin" thing is something people just need to learn. But even back in the Flash version, we automatically activated a bunch of common plugins in TweenMax because it was geared to be the robust, "plop it in and forget it" option. Sure, we could require people to manually load each of those common plugins instead, but: You'd be surprised how many people struggle with that. We want to reduce friction for developers. Think of TweenMax almost like a Lexus car that has a bunch of plush features and conveniences built in. A sports car racing enthusiast might turn up his nose and insist that if they removed the fancy big-screen GPS, sunroof, TV screens behind the headrests, and swapped out the plush suspension for a stripped-down sporty rendition, they'd shave off several hundred pounds and make it faster. But the typical Lexus customer doesn't care about that - they'd much rather have the conveniences. Likewise, TweenMax isn't aimed at people who are obsessing about file size (TweenLite is for that). You might actually end up with WORSE loading performance due to latency. Loading one 33kb file is typically much faster than loading 8 files that add up to 28kb. Then again, I realize that you are planning to squish them all into a single JS file during your build process, so that negates this point in your particular case, but there are plenty of folks out there who want to load TweenMax over a CDN link and this "rip out all the plugins and make them load them manually" would affect them. Anyway, we do plan to move to ES6, so some of those will be moot at that point (though we still plan to have a compiled TweenMax.js file that has a similar bundle of common plugins and timeline classes, even after we move to ES6). Thanks for the discussion and suggestions!

Yeah, if you've got an infinitely-repeating tween in a timeline and you're trying to do some sort of relative positioning, that's gonna be tough because that tween literally takes almost forever to finish. You can definitely work around that by simply using a variable or use absolute values or use the recent() method that spits back the most recently-added child. So if you wanted to tweens to overlap by 1 second, here's some pseudo code: tl.to("#id", 2, {repeat:-1}); tl.to("#otherID", 3, {...}, 1); //absolute value tl.to("#otherID", 3, {...}, tl.recent().startTime() + tl.recent().duration() - 1); //using recent() var time = 0; //variable for tracking insertion point time += 2; //after inserting each tween, add its duration to the time tl.to("#otherID", 3, {...}, time - 1); So there are 3 different ways to handle it. But frankly, I'm the biggest fan of using the nested timelines like you mentioned because I think it affords even more flexibility and it keeps your code more modularized and easy to read. Glad you got the IE stuff solved. Browsers are still a little weird these days about little SVG quirks like that. I was looking at Firefox 47.0.1 on a Mac. All the gears rotated around their centers. Did you make sure you were setting transformOrigin:"50% 50%" or "center center"? It looked like you were defining only one part of the value, like "center". Not sure that'll solve anything for you, but it's worth a try. Like I said, things looked fine on my system.

According to my research, "zoom" is not in the CSS spec, and it is generally frowned-upon in favor of transforms. Not only do transforms have better support (Firefox and Opera offer no support for "zoom"), but transforms also don't affect layout thus they'll perform better. https://css-tricks.com/almanac/properties/z/zoom/ http://stackoverflow.com/questions/10278783/what-does-zoom-do-in-css Again, I'm pretty sure you could resolve this by simply using transforms to do your "zooming".