GreenSock

Thanks for reporting back with your findings (and solution). Glad you figured it out

That error you described indicates you've got something else going on in your environment that's doing some odd things, like maybe messing with the Object prototype or something. It's very difficult to diagnose blind, though. Can you please provide a reduced test case in codepen or jsfiddle that we can look at? If you're not sure how, please take a peek at http://greensock.com/forums/topic/9002-read-this-first-how-to-create-a-codepen-demo/

It looks to me like the problem is that on the subsequent tweens, you're animating elements that aren't even visible (visibility:hidden). I suspect that you meant to animate the same two shapes to various states, thus you're targeting the wrong things. So let's say you start with #keyframe1 and you morph it to #keyframe2...remember, the actual element itself is still technically #keyframe1 (it just has the shape of #keyframe2 now). So if you then want to animate it to #keyframe3, the target (the thing you're animating) would be #keyframe1, not #keyframe2 which is just a hidden element you were using to pull shape-related data from. I also assume you wanted the two shapes to animate at the same time to both states, but you were using "+=1" as the position parameter for the subsequent ones, meaning it would just sequence them with 1 second inbetween (gap). So I think you meant for your code to look like: tl.to("#keyframe1", 1, {morphSVG:"#keyframe2"}, 0) .to("#keyframe3", 1, {morphSVG:"#keyframe4"}, 0) .add("scene2", "+=1") .to("#keyframe3", 1, {morphSVG:"#keyframe5"}, "scene2") .to("#keyframe1", 1, {morphSVG:"#keyframe7"}, "scene2"); I just used a label, but you could do it with absolute times if you prefer. Does that help?

That looks like a Safari rendering bug (unrelated to GSAP) when any 3D transforms are applied to the element. By default, GSAP will automatically give you GPU acceleration when animating transforms by promoting the element to its own layer (it does this by using 3D transforms). Apparently Safari doesn't like that you set margin:auto which places it right in the middle, meaning that the border lands on a half-pixel value and it botches the clipping. You have two options: either set force3D:false on your first tween (that setting remains intact unless you specifically change it) to remove the GPU acceleration and force the browser to do the rendering on the CPU, or set left:1px on the container instead of 0px (that seemed to fix it for me at least).

Sheesh, I think I'm as confused as you are. And unfortunately I've already gone bald (well, shaved my head but still...no more hair to pull). A few questions: Are you 100% positive you're using GSAP 1.19.0? (Might you have a different version cached or something?) You are using babel as well as the latest Webpack, right? (GSAP isn't written in native ES6 yet) Can you send me a reduced test case so that I can easily reproduce the problem locally? I'm sure we can get to the bottom of it. I was able to get it working just fine with Webpack and babel. None of the errors you mentioned. [scratching head]

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.