GreenSock

The book doesn't require any of the special plugins, no. It's written to focus primarily on all the core (free) tools. You can absolutely get a lot out of it without ever joining Club GreenSock. Thanks for asking.

@huyhungkun, can you provide more details? I just tried compiling TweenMax here: http://closure-compiler.appspot.com/home and turned advanced mode on. I got several warnings, but zero errors. The warnings were all about perfectly valid stuff. Can you help me understand exactly what problems you're running into?

I even tried isolating that one fade with the same HTML and CSS (I think) without React and it seems to work fine in IE: http://codepen.io/anon/pen/oLbGeo (I slowed down the fade to really study it). It sure seems like React is interfering somehow but I can't identify exactly what's happening yet. Got any theories? I'm probably missing something obvious.

Thanks for throwing that codepen together, Blake. Could you elaborate on what "styling problems" there are? When I inspect the DOM, it does seem like GSAP is doing exactly what it's supposed to (opacity is fading when the video exits), but visually the video doesn't fade in IE (it does in the other browsers). I'm trying to diagnose what's causing that exactly. It's weird because again, the value appears to be getting set properly the whole time; it's like a rendering issue or something. Any ideas?

I'm not familiar with React at all yet, but I hope to look into it soon. My understanding, though, is that one thing that makes React a bit tricky to deal with is that it mutates the DOM underneath you, meaning the element that you started with (and began tweening) might be completely deleted and a new element rebuilt in its place...whenever React decides it's "best". I wonder if perhaps that's the problem you're running into here. Like maybe GSAP is animating the properties correctly, but that element is swapped out for a different one by React and that one isn't animating properly because the reference fed to GSAP is the old one. Tough for me to say without React experience or know-how yet. Perhaps someone else here who has some React knowledge could chime in? Generally we much prefer that you provide a reduced test case in codepen if at all possible so that we can poke around and see what's happening. You wouldn't happen to have something like that, do you?

Absolutely, @Severson12, you are welcome to play around with the bonus plugins as much as you want on codepen without purchasing anything. You can fork any of our pens there (tons of collections at http://codepen.io/GreenSock/collections/popular/) or here's a pen that loads all of them and has the special codepen-specific URLs listed: http://codepen.io/GreenSock/pen/OPqpRJ Let us know if you or your boss have any questions. We hear frequently from customers that the membership pays for itself in literally a matter of days when you factor in the time GSAP saves, the increased capabilities and performance, etc. But rest assured that there's a 100% money back guarantee so if for some reason you don't like it, we don't want your money. We want customers who are thrilled with what they get. Happy tweening! Have fun on codepen

Here's probably the simplest way to do it: var tl = new TimelineMax({repeat:-1}); tl.from("#stroke1", 1, { drawSVG: "100% 100%", ease: Expo.easeInOut }).to("#stroke1", 1, { drawSVG: "0% 0%", ease: Expo.easeInOut }); To do it without the timeline, you could have set repeat:-1 and repeatDelay:1 on your tweens, and overwrite:false on the 2nd one, but I think the timeline approach is much cleaner and it gives you an easy way to control the animation as a whole as well. For example, pause(), resume(), timeScale(), reverse(), or whatever. Happy tweening!

Ah, very interesting. iOS Safari acts very strangely in that case. After a bunch of research, I think I crafted a workaround and dropped it into a preview (uncompressed) here: https://s3-us-west-2.amazonaws.com/s.cdpn.io/16327/Draggable-latest-beta.js Better?

Yep, PointC is exactly right. And I wanted to point out that there is no pre-defined list of properties that you're "allowed" to animate with GSAP. It can animate almost any property of any object. For example: var obj = {mySillyProperty:20}; TweenLite.to(obj, 2, {mySillyProperty:100, onUpdate:function() { console.log(obj.mySillyProperty); }}); That'll animate obj.mySillyProperty from 20 to 100 over the course of 2 seconds and log the values on each tick. My point is that it's super flexible and it's not limited to some list of properties. Most CSS properties just work. Give 'em a shot. And we created a few "special" ones for special cases, like rotation, scaleX, scaleY, x, y, autoAlpha, etc. just to address specific needs (like independent control of transform components). Happy tweening!

I noticed a few issues: You're applying transforms both in the CSS and in JS. Transforms on SVGs are especially tricky to do in a cross-browser way and I strongly recommend just applying them with GSAP because it solves pretty much all of those issues. In this case, the major problem is that Safari prioritizes CSS transforms over the transform attribute, whereas other browsers are the opposite. By default, GSAP applies its transforms on SVG elements to the "transform" attribute (not the CSS style) because it's the most reliable. Safari has several bugs, for example, if you apply them in the CSS (like z-index rendering can get all funky). But since GSAP was applying them in the transform attribute, and you had competing transforms in the CSS, Safari was completely ignoring the transform attribute in favor of the CSS stuff. Again, if you just do all your transforms via GSAP, you won't have any of these issues. In your CSS, you had prefixed versions AFTER the regular (non-prefixed) version - it's best to invert that. It wasn't causing an issue here, but I wanted to mention it. Be careful about applying CSS transitions to the same elements you're animating with GSAP, as they can conflict. It wasn't causing the problem here, but I figured I'd mention it.

Never heard of anything like that before. Sounds like either a rendering bug in the browser itself, or a GPU problem. I wish there was a solution I could offer from our end of things, but I can't think of anything.

Not sure if it'd solve it, but did you try setting overflow:visible on all the <div> elements for the letters?

smoothOrigin is for SVG only, that's correct. There haven't been enough community requests to justify porting that to regular CSS transforms as well yet. We'll keep listening though. As for Double-click recognition, I can't imagine how GSAP could possibly interfere with that. Feel free to do a test and just remove GSAP from the equation and see if it works. If you think it's GSAP, please create a reduced test case in codepen and send it our way; we'd be happy to take a peek.

Oh! Now I understand - you were just missing the preserveAspectRatio attribute on your <image>. Remember, in SVG, by default it'll preserve the aspect ratio and fit within the size provided, so you want to turn that off, like <image id="end_maskImg" preserveAspectRatio="none" x="0" y="0" width="499" height="400" xlink:href="http://www.christiantants.com/assets/masking/end_mask.png" /> That had nothing to do with GSAP. You could remove GSAP from the equation entirely and hard-code the values you had in there and you'd see the same behavior. https://developer.mozilla.org/en-US/docs/Web/SVG/Attribute/preserveAspectRatio Does that solve things for you?

Can anyone else reproduce this issue? I'm really not sure how to proceed here. I want to help...just struggling to determine how, since I can't see the issue at all. I don't think anyone else has reported a similar issue either. [scratching head]

Gosh, that definitely sounds like an issue with other JS on that site (unrelated to GSAP). We really try to keep this forum focused on GSAP-specific questions/issues. If you have a reduced test case in codepen or jsfiddle that indicates it's a problem with GSAP, we'd be happy to take a peek. We definitely want to make sure things on our end are working perfectly. But yeah, those errors sure sound like some sort of module loading problem or something along those lines.

That's what's baffling to me - every time I scroll my mouse wheel (while the scrollTo tween is in-progress), it shows the alert() exactly as it should. I'm so confused. What browser/device are you testing on? And no, there isn't a way to make it more or less sensitive.

I see what you mean, but that's only necessary if the length is greater than 1. Skipping it in that case (1) allows us to improve performance for the vast majority of users (when people don't add extra "tick" listeners). https://s3-us-west-2.amazonaws.com/s.cdpn.io/16327/TweenMax-latest-beta.js

I just checked Dev Tools and it looks like GSAP is doing exactly what it's supposed to. The x and y attributes are both 0, width is 500, and height is 50. Am I looking in the wrong place? Are you just saying that the browser itself isn't rendering things properly (even though GSAP is setting the attributes exactly the way you requested)?

@OSUblake, no, it's not really based off of that. In my tests, that [relatively common] algorithm looked a little funky in some situations (especially when there's one anchor super close, and another very far away) so I crafted my own that I think looks more natural.

This isn't really a "bug" per se because we specifically state in our docs that camelCase should always be used. It's kinda frowned-upon in the JS world to use hyphens in property names like that. GSAP has some specific logic that runs when the property name is textShadow that helps normalize the values that it gets from the browser, but since "text-shadow" was used here, that logic wasn't employed. Chrome was reporting the current (computed) style with the color FIRST in the list, like "black 5px 5px" and that doesn't match up right with "5px 5px red" (the color is last in the complex string). That's basically where things broke down. But again, "textShadow" has logic in CSSPlugin to normalize all that. The moral of the story: always use camelCase

I'm a bit confused - autoKill already does fire when the mouse wheel is scrolling. Are you just asking how you can set up your own separate listener for that type of thing apart from GSAP?

Glad you found something that worked for you, although that's not a nested timeline. Here's what a nested timeline would look like: var mainTL = new TimelineMax() mainTL .to("#moving", 1, {x: 100}) var otherTL = new TimelineMax(); otherTL .to("#move", 1, {x: 100}); mainTL.add(otherTL); //<-- this is nesting This solution will work great backwards and forwards whereas the way you did it wouldn't really give you a timeline that's completely controllable in any direction (seek, reverse, whatever). I'd highly recommend watching/reading these: http://greensock.com/sequence-video http://greensock.com/position-parameter Happy tweening!

Hm, how exactly can we reproduce the problem? Your code references "this.hash" but I'm not sure what that is, and in its absence your code never even attempts to call the autoKillFired() method. Did you perhaps intend to set onAutoKill:autoKillFired on the first tween too? I'm not aware of any bugs in ScrollToPlugin.

It looks to me like a logic issue in the code and the fact that you're using "from()" tweens. Remember, those will always use the CURRENT value (when the tween starts) as the DESTINATION value. In your case, after the first click (well, after you close the popup), the opacity is 0. So the next time you try to do a from() tween, it's animating from opacity:0 (the current value) to opacity:0 (what you passed into the tween). See the problem? But since you're using clearProps at the end, it removes those inline styles and POOF, the element becomes visible because the default opacity is 1. So it seems like it's not animating anything even though GSAP is doing exactly what it's supposed to. You could just use fromTo() tweens so that you can define both the start and and values. //OLD: tl.from(shade, 0.5, { opacity: 0, clearProps: "opacity" }); tl.from(block, 0.5, { opacity: 0, y: -75, clearProps: "opacity,y" }); //NEW: tl.fromTo(shade, 0.5, { opacity: 0}, {opacity:1}); tl.fromTo(block, 0.5, { opacity: 0, y:-75}, {opacity:1, y: 0 }); You could add the clearProps into the "new" ones above if you want but I'm not sure what the value would be.