GreenSock

The plugin hijacks most animate() calls but there are a few function calls that it doesn't intercept like show(), hide(), and toggle() because of some legacy issues with jQuery and some special ways it likes to handle things. I'd say that the jQuery plugin is a great drop-in to get good bang for your buck (very little time/effort), but I'd strongly recommend shifting to GSAP's regular API when you can. I think you'll find it much more flexible.

Hm, I read your question a few times and I'm still not quite sure what the question is. Would you mind elaborating a bit? Are you asking about the best way to rebuild that codepen so that it doesn't use a timeline and ScrollToPlugin? Was there a particular functionality you want but can't achieve?

@determin1st I'm confused. Do you have an example of it not working properly? Like maybe a super simple codepen? I'm not seeing any odd behavior but maybe I'm missing something.

Sure, I think we can accommodate that for ColorMatrixFilters. I updated it here - does this work well for you?: https://s3-us-west-2.amazonaws.com/s.cdpn.io/16327/PixiPlugin.min.js

Hm, it doesn't look like that code would draw anything, but maybe you just wanted to reverse the order in which the circles animate their scale? If so, try setting the stagger value to -0.1 instead of 0.1. Does that help?

It looks like the main problem is that you're using a single TimelineLite for all of your animations even though they're non-linear and the timing is dynamic. There are many ways to fix this, but probably the easiest one is to just declare a new "tl" variable in your open and close handlers: That way, their timing starts fresh each time. Previously, since you were dumping everything into a single timeline, the playhead would reach the end and then later when you added more tweens to the same timeline, its playhead would jump ahead because its startTime was so far in the past (and time had elapsed). It's not a bug - that's how it's supposed to work. But in your case, it looks like you wanted things to behave differently (fresh timing each time). Does that help?

Hm, I'm on a Mac with the latest OS and Safari. I don't see any borders at all

No problem: Transforms are relative to the element itself (50% = 100px above), and top/left are relative to the element's container (50% = 300px above). Does that clear things up?

Yep, I generally prefer x/y (transforms) but there are some cases when you really need some of the benefits of top/left. You mentioned that your goal was to make things responsive, and an important thing to keep in mind is that transform-related percentages are based on something COMPLETELY different - the element itself rather than its container. So top/left percentages refer to the parent element's width/height but x/y refer to the element itself's width/height, making it very difficult to achieve certain things. For example, when I built GSDevTools, I had to use a percentage-based "left" value for the scrubber and other positioning so that things lined up perfectly when the user resized the browser. I suppose you could do calculations on every resize to set the proper x/y but there are down sides to that too.

Excellent. I just added a note to the docs about this to help others who may run into the same thing.

The only reason I can think of that'd cause a plugin to remain in _gsQueue is if _gsScope._gsDefine isn't defined which basically means that the core TweenLite hasn't loaded (and TweenLite is inside TweenMax, so as long as that's loaded, you should be fine too). I'm not very familiar with how a lot of these transpilers/bundlers do things under the hood but it sure sounds like an issue related to that since we know that importing the way you just suggested works well in virtually all the transpilers/bundlers.

Hm, from what I can tell, this [probably] isn't a bug. The issue is that you're calling exportRoot() literally 100,000 times and each time, it basically wraps all the animations on the root timeline into a TimelineLite. So you've got things nested 100,000 levels deep. The browser is assuming this is a recursion error simply because there are so many calls to one function. For example, the first time you call exportRoot(), it wraps everything. The next time, the only thing on the root timeline is that previously exported stuff in a TimelineLite, thus it wraps THAT TimelineLite inside a TimelineLite and returns that. Same with the next time you call exportRoot(), and so on. Therefore, when the root timeline's render() method gets called, it loops through its children and calls their render() methods accordingly, and those do the same to their children, and so on. That's exactly how it's designed to work. But notice that the TimelineLite.prototype.render() method is getting called a ton of times in a row. One way to avoid this is to add some logic to avoid excessive nesting. Maybe dump them all out of your exported root before you call exportRoot() again, like: //De-nest things from the "allTweens" exported root... if (allTweens) { var animations = allTweens.getChildren(), startTime = allTweens.startTime(), root = allTweens.timeline, l = animations.length, i; for (i = 0; i < l; i++) { root.add(animations[i], animations[i].startTime() + startTime); } allTweens.kill(); } allTweens = TimelineLite.exportRoot(); ... Does that help?

Wow, that is one of the weirdest bugs I've seen in a long time. Definitely a Safari SVG rendering bug. If you look at the resulting HTML/CSS that GSAP sets, it's identical between Safari and other browsers. I poked around and found that if I changed your <line> elements to be <path> elements instead, and made sure to avoid using the regular "L" (line) command (I used Cubic bezier instead), it suddenly fixed the issue! Here's a fork: It's actually not that hard to convert lines into paths. You just slap an "M" at the front (move), then put the first x,y, then put a "C" and the final x,y coordinates 3 times. Like this: <!--OLD--> <line x1="10" y1="25" x2="40" y2="25" /> <!--NEW--> <path d="M10,25 C40,25,40,25,40,25" /> (there are other ways to do it, of course, but that's a simple one) Does that help? I don't think this "fix" should be automated in GSAP because it involves some pretty significant changes to the underlying DOM that could mess people up. Like in your case, you had a selector looking for "line" elements, so if we just automatically changed all of those to <path> elements, your code would break because the selector text wouldn't apply properly anymore. I wish there was a super simple fix we could apply. But again, this is definitely a Safari rendering issue, not a GSAP issue.

I'm not aware of any issues like that, no. It may be a video card (or driver) issue. Have you checked other PCs? Also, I'd be curious if it makes any difference if you set force3D:true or force3D:false.

Sorry, I'm still not sure how to answer this. Are you saying the fonts are fuzzy? And are you asking us to tell you how to build a whole site like that? Did you have a GSAP-specific question? We really try to keep these forums focused on helping people with GSAP questions.

Hm, I didn't quite understand what kind of answers you were looking for. Did you have a specific question about GSAP? Or were you wanting people to tell you how to build a whole web site like that one? It sounds like there was some problem with fonts not being smooth? Can you elaborate?

Yeah, that's a pretty tricky scenario. You could do this:

Thanks for the reduced version Wouldn't your original idea of x:0, y:0, scale:1, rotation:0 do it? And then at the end of that, if you want to remove the svgOrigin and stuff, just use a set() in an onComplete?:

Hm, I think you're misunderstanding... When you animate "x", that affects the CSS transform property, like "transform: translateX(...)". So no, it should NOT be setting the "left" property. That's something totally different. The codepen you mentioned is working exactly as I'd expect. style.left should indeed return "". Here's a fork of that codepen that uses "left": Seems to be working as expected. Again, if you're still having trouble it'd be super amazingly awesome if you could pretty please provide a reduced test case in codepen or jsfiddle or even a live site I guess.

Sorry, it's just REALLY hard to tell you what's going on without seeing it. Any particular reason you don't want to post something we can look at? That'd sure help. In your first example, you're animating the "top" but you're checking the "left" property in the debugger. Once I can see the problem in context, I'm pretty confident I'll be able to give you a much more solid answer.

It's tough to diagnose without a codepen or something, but I'll mention a few things: _gsTransform is only for transform-related values (x, y, rotation, scaleX, scaleY, xPercent, yPercent, etc.) NOT for top/left or any other CSS values. I wonder if you're running the console on a different document. For example, if you have a codepen open in editor mode, it's running the results inside fo an iframe, so if you try running document.getElementById("bullet").style.top on that top/parent window, it won't find the one that's inside your codepen. Make sure you don't have multiple elements with "bullet" as their id. If you're still having trouble, we'd be happy to look at a codepen demo (or jsfiddle or whatever).