GreenSock

That is indeed weird and I wonder if there's something odd being hijacked elsewhere because that particular statement that it's throwing an error on is a conditional expression like this: if (typeof(obj) === "object" && obj.step) { ... And it's saying obj is null (thus obj.step would throw that error) but that's the whole point of that first part where it checks to see if it's an object so I'm having a tough time understanding how it could possibly even get past that line in the condition unless null has somehow been hijacked to act as if it's an object (never heard of that). Something tells me that there's some other JavaScript that you're loading that's causing some very odd conflict (though I'm not sure because there's so much going on and I don't have time to pull everything apart on that page which is why others are asking for a reduced test case...that'll help a lot).

It looks like that animation is using CSS animations, not GSAP. This forum is dedicated to GSAP solutions. Are you asking how to do that with GSAP?

It was indeed an issue in CSSPlugin that would show up if you tweened skewY and then subsequently tweened skewY, skewX, or rotation (those are all intertwined in the matrix). It should be resolved in the 1.18.3 preview of TweenMax which you can see here: https://s3-us-west-2.amazonaws.com/s.cdpn.io/16327/TweenMax-latest-beta.js (uncompressed). Does that work well for you? I apologize for the glitch.

I'll look into this and get back to you. Skewing on the y axis is indeed tricky because of how it contaminates rotation values in the matrix. I'll figure something out...stand by.

GreenSock doesn't have it's "own" filters - it simply changes the regular (built-in) Flash filters many times per second

Well said, PointC. Couldn't agree more. Asking your questions will help you grow and nobody here is judgy about "stupid" questions. Then, when you start helping others here, you will grow exponentially. Hanging out in these forums is probably the single most effective way to learn, even more than reading the tutorials and watching the videos. Thanks to all who contribute to making this such a warm and welcoming place, yourself included PointC.

It was indeed an edge case that would affect the RegExp responsible for swapping in the class name, and it should be fixed in the latest preview of 1.18.3: https://s3-us-west-2.amazonaws.com/s.cdpn.io/16327/TweenMax-latest-beta.js (uncompressed). Thanks again for pointing this out, and sorry about the hassle.

Here's another sneaky way to do it: //calls yourFunction 5 times, with 0.25 seconds between each: TweenMax.to({}, 0.25, {onRepeat:yourFunction, repeat:5});

Thanks for reporting this and yes, it looks like a very rare edge case that needs to be fixed. It'd only happen when you're using a substring that already exists in the list of classes and there's a hyphen or underscore directly next to it. I should have a solution for you tomorrow. Please stand by.

No problem. Thanks for letting us know. Glad to hear it wasn't a problem with our stuff

Yep, Zach is exactly right. In fact, GSAP is more compatible than CSS animations. It even works in IE8 (although we may remove that in an upcoming version in order to streamline things and almost nobody uses IE8 anymore). CSS animations don't work in certain browsers on SVG transforms, and [as you probably discovered] they're much more difficult to work with and edit/maintain. So not only does GSAP offer better performance, but it can do a whole lot more than CSS animations: better easing (Elastic, Bounce, Rough, SlowMo), independent control of transform components, animating along a path, morphing SVG shapes, scroll-based animation, runtime controls, and lots more. See the following articles: http://greensock.com/why-gsap/ https://css-tricks.com/myth-busting-css-animations-vs-javascript/ http://greensock.com/css-workflow/ http://greensock.com/transitions/ Happy tweening!

Are you talking about the ActionScript version or the JavaScript version? Any chance you could provide a reduced test case FLA or something?

You've got conflicting tweens. Your first one starts at the 8-second spot and lasts 4 seconds, but you're tweening the same property ("y") of the same element to a different value starting at a time of 11.5, thus it overwrites (and kills) the first one once it kicks in. Thus when you go backwards, that original tween doesn't kick in (it was killed/overwritten). Generally it's a bad idea to create conflicting tweens like that, and GSAP automatically kills the first one assuming you don't want tweens fighting with each other. But you can just add overwrite:false to the 2nd one if you don't want it to overwrite anything (just beware that it'll leave those two conflicting/overlapping tweens in there). tl.to('#eau', 4, { y: 1400, }, 8) .to('#eau', 1, { y: 0, overwrite:false //<-- add this }, 11.5) .set('#eau', { autoAlpha: 0, }, 12.5) .pause(); Does that clear things up for you?

Hm, I didn't quite understand your first question ("why and how can it be that *empty* sometimes can prioritize over any js addClass, classList (active, hover and other possible additional class), only when using gsap className in food-chain?"). Are you asking why the tween would overwrite the list of classes? If so, it's because it must do so to honor your instructions. When you set a property to tween, the engine must make sure it's setting that value over the course of the tween so that, for example, if that animation was in a timeline and then much later (after the animation finished and you altered that property in other ways), if you seek() to a certain spot in that animation or reverse() it or whatever, the values would display properly. If we didn't do that, you'd get weird behavior in certain scenarios where an animation just doesn't seem to work properly after the first time it runs. Let's say you start with class="" and tween to class="hover", then that tween finishes, and you manually set class="active" and then tell that first tween to progress(0.5). You shouldn't see "active" in the list of classes because the tween needs to set it to what it's supposed to be during that tween ("hover" in this case). Again, that's not a bug at all - it's the correct behavior even though I can see why you'd think it's a problem in your scenario. You asked if there's a reliable way to prioritize js "active" over "hover" - sure, that was my recommendation #1. Just set() it through GSAP instead of having bootstrap or other framework do it. Or you can just call TweenLite.killTweensOf(element) before you set the class to active. Does that answer your question?

Just a little tip if you want to make the code even shorter: //works great: menu.reversed() ? menu.play() : menu.reverse(); //even shorter: menu.reversed( !menu.reversed() );

Thanks for creating the codepen demo. Very helpful. I think I know what's going on and as odd as it may sound, I don't think it's a bug in GSAP. Or perhaps I'm misunderstanding, but allow me to explain my train of thought... The issue seems to happen when you've got a tween happening WHILE you click on that same element and then 3rd party code alters the classes on that same element (bootstrap in this case). A className tween tells GSAP to tween from a particular class (or set of classes) to another. Period. So let's say you start a hover tween that tweens from className "" (empty) to "hover". GSAP must record both of those values and make sure they're applied properly during the tween. Great. Now let's say while that hover tween is happening, you click and bootstrap chucks another class into the mix ("active"). GSAP has no way of knowing that, and it continues doing its job of animating from "" to "hover". See the issue? Think of it kinda like if you were tweening the color white to black using GSAP, but then halfway through that tween, you manually set that property to red, like element.style.color = "red". You might see that for a split second, until the next tick when GSAP sets the value to gray and continues on toward black. That's not a bug. The only ways around that would be: Set that color through GSAP, like TweenLite.set(element, {color:"red"}) so that its overwriting algorithm kicks in and stops the original tween. Or GSAP would have to constantly monitor every value to watch for outside changes which would exact a HUGE performance penalty. GSAP is highly optimized for performance, so it rips through its rendering tasks very quickly. If it had to say "wait, are you still gray? Doh! Someone set you to red...let me recalculate everything and go from red to black now", that'd really slow things down. Plus if you reverse() that tween it wouldn't be able to go from black to red to white because a single tween cannot have a variable number of states (a tween goes from one value to another, so basically 2 states - beginning and end). Does that clear things up at all? Frankly, I'm not a big fan of className tweens for 2 reasons: They require looping through every property to see where any changes are, and then isolating those. Not ideal from a performance standpoint (but it's unavoidable in JS). It's much, much faster to just define the properties you want to animate. If you're just swapping classes and want them to transition, CSS transitions are entirely adequate and likely faster. They fit into the CSS-centric mindset which is where most people who do className tweens tend to live. Thanks again for bringing this up after it's been gnawing at you for so long so that we can explore it.

No, I don't think Flash removes items from memory that have negative x/y values. Sorry. That could actually have a lot of negative consequences if it did that

Can you describe what you mean by "after nothing has happened after a period of time"? Are you saying that if the user interacts with the page in any way, it would start the timer over again (thus not restart the animation)? So a scroll, a mouse move, a click, or anything like that would prevent things from restarting? Or are you just saying that you want your animation to repeat with a certain amount of time inbetween each iteration?

Great feedback. And yes, I had already had switched "n" for "m" a few days back. It has been in the official downloads too

You're absolutely right - I see what you mean. I believe it should be fixed now. Thanks for bringing that to our attention. Let me know if it works well for you now.

I don't see any obvious errors, but it might be choking on it because you have a decimal with no leading 0: //Bad? scaleX:.2 //Good scaleX:0.2 (GSAP doesn't really care, by the way - it sounds like you're working with a picky compiler )

I appreciate you asking permission about proceeding - I just don't feel like I'm in a position to make that decision for you. Based on the fact that nobody has cast a single vote yet, I think they're all in a similar boat - there's not enough info yet in your repo to determine how closely the API matches. Maybe once your docs are more filled in and you have a lot of examples, then people might feel more comfortable offering feedback or voting in the poll. I'm kinda curious why you felt the need to create this library in the first place, especially if you were a fan of using GSAP. Is there something we could do better? Is there a deficiency we could shore up somewhere? (Not that there's anything wrong with creating another animation library - I'm just trying to understand the motivation and whether or not we've let you down somehow). Best wishes!

Congratulations on all your efforts. And thanks for the kind words about GSAP. I guess they say that copying is the most sincere form of flattery We certainly don't claim to "own" a certain syntax. I must admit, however, that it can be a little discouraging when we sink so much time into crafting the API and codebase and then someone copies large portions of it and releases a competing library as a "free" alternative and then asks for our blessing. But I've learned the hard way over the years that writing the code is one of the least time-intensive parts of the whole endeavor when releasing a library for public consumption. It's dwarfed by all the ongoing support demands, documentation, refinement, bug fixes, etc. which is why we don't use an MIT license (see http://greensock.com/why-license/ for more details). I totally understand how exciting it can be to create something like this and share it with the world, and I wish you the best. I can't really endorse your library/API but as long as you're not using any of our code you should be fine. It sounds like you didn't really copy anything except portions of the syntax. Good luck with your project, and happy tweening!

That is indeed better, Blake, thanks. Is it not necessary to escape the "+" symbol though? And if we're adding "ig" at the end, there's no need to specify both "e" and "E" since it's case-insensitive, right? So perhaps it should be: /[\-\+]?\d*\.?\d+e[\-\+]?\d+/ig By the way, I had never seen that regex101.com tool. Amazing!

Thanks for the info, Blake. And yeah, I think in the next major release, we'll strongly consider dropping support for IE8 and earlier.