Chromium

This is unfortunate, because I was hoping you'd have a better understanding of what was happening. If I could make a demo of this, then I'd have the answer to what is happening and wouldn't even have needed to post this ? I've tried adding t1.invalidate() after the t1.progress(1).kill() but that didn't seem to do anything. I've also tried t1.restart().invalidate() as you suggested but that doesn't make sense to me for my use case... as that seems to simply restart the timeline with the same old value for the TextPlugin tween. I've also tried t1.time(0).invalidate() to no avail. But at this point I'm just guessing, as I simply can't wrap my head around why there would ever be a case (such as this) where I'd need to re-write the t1 variable... I thought t1.progress(1).kill() would simply be enough. I was hoping that having found a solution to the problem would replace the need for a demo, and it would be one of those things that immediately clicks to you guys because (and I'm presuming) that there's only very few case scenarios that would require a re-write of the t1 variable (and that there's some explanation to having the need to do this and/or an equivalent standard timeline method to re-writing the t1 variable). This sucks but I guess I'll have to settle to never understanding why my solution worked! Thanks anyway Note: That demo on the invalidate page really helped clarify the purpose of that method in my head. I previously thought it might be part of the more appropriate solution to my use case, but after looking at that demo, I don't think it applies to my use case. At least, from the way I understand it, what I simply require is that on subsequent clicks, my timeline needs to reset and add (and immediately start playing) new tweens in place of the old ones (they're more or less the same tweens with the exception of the TextPlugin tween just having a different value). It's just that in my head, I didn't expect that this use case would require a re-write of the t1 variable, or for that matter, I didn't think any use case required that, but I may be wrong and that my use case is an exception among some others haha.

So I'm going to try to explain this but I can't even understand what's causing it so I probably won't explain it right. I've got a timeline with a few tweens in it. The timeline is created on page load but the tweens are only added on the click of a button. Every time the button is clicked, this line is executed first: if (t1) t1.progress(1).kill() As I understand it, the above line is meant to kill any previously (still) running timelines (in scenarios where the button is clicked too fast for example). So far so good, this all worked fine. This may be irrelevant but I should mention that I do run a t1.pause() by the end of the timeline (because one of the tweens is an infinite tween that I'd wanted to stop once the timeline finished). Of relevance: one of the tweens in this timeline is running the TextPlugin and setting a text value provided through a variable in JS. What this meant is that on each subsequent button click, I'd need to restart the timeline but with a different value for the TextPlugin tween. I assumed that the easiest way to do this is to simply re-run all the functions that added the tweens to the timeline (as this would automatically also add a new tween with the updated TextPlugin value). However, this didn't work out as expected... and I'm not sure how to explain it either. On subsequent button clicks, I tried: t1.progress(1).kill(), t1.progress(0).kill(), t1.progress(0), t1.play(), and a mix of them together... none of these solved the issue. The only thing that finally worked was simply re-defining the timeline variable (t1) on each subsequent button click (after running the t1.progress(1).kill() in case anything is running already). Since I've already resolved it, I'm only posting this hoping that someone here knows exactly why re-defining the timeline variable was necessary to get this to work? And if so, is there a more appropriate way for such a scenario (as opposed to re-defining the timeline) that I've missed?

I completely forgot I had stagger on to be honest. That was screwing with my head ? And ease is exactly what I was looking for, thank you!

Hi again @GreenSock, Follow-up question for you regarding this. After setting up my Flip animation how you suggested, while the animation is working and running smoothly, I'm wondering how come it is not following the same order of animations when going back to the initial flex-direction (on the 2nd click). See the GIF example below: To elaborate, notice how on the first click, it animates the clicked image and then the text (or at least it appears that way) whereas on the subsequent click, it animates the text first and then the image? Is there a reason for the order of animations here? And do we have any control over it? Additionally, can we control which kind of animation it is or what path the animation takes?

Hahaha thanks for bearing with me. Reading your last response and applying everything in it literally seems to finally have done the trick! I guess what I struggled with the most is assuming that by including a parent (both in the getState and absolute), its children (and all their children, etc) would automatically be included in the animation as well. Essentially, for this to work, my getState had to have an array of every single element from Parent 4 and everything inside it (as you said), while my absolute had an array of everything getState had minus Parent 4. Thanks again for all your help. Love all the plugins you guys keep making that makes our lives so much easier and brings more life to websites! It's always fun animating with your library! ? I love that I didn't even need to do anything else for mobile, just added a max-height and Flip does the rest of the magic! PS: Since a parent and its children are included in this case, it seems imperative to include nested: true, but oddly enough, adding/removing it doesn't seem to make a difference here (at least not visually).

My thoughts as well... because it works when I do absolute: true but then the layout collapses because the parent becomes absolute during animation I guess. I've tried absolute: [child, child], absolute: [parent, child, child], absolute: parent... I'm kind of guessing at this point. This is a GIF of what's happening btw, it's not just my eyes, right? There's a little jump when it shrinks... it's skipping something. Perhaps you can help me understand, based on this GIF, exactly which elements' states would the Flip plugin need and which elements' need to be excluded from the absolute positioning during the animation? To give you an idea, this is the current element hierarchy in the GIF above: Parent 1 Parent 2 Parent 3 Parent 4 // This is the parent with the background (so it needs to be animated as well). Parent 5 IMG WRAPPER IMG PARAGRAPH DIV So my initial thoughts with this hierarchy would be to getState(Parent 4), absolute: Parent 5, and put nested: true (so that the animation would apply to its children as well)... but that didn't work (the IMG/Paragraph elements simply didn't animate).

I know we can provide the getState method multiple DOM elements (as you have shown in your example), but is it possible to provide that method multiple jQuery objects? I tried that in the CodePen below but "the jumps" make me think it didn't work (this may be related to my other problem). I've also tried putting the objects in an array but that didn't seem to stop the "jumps". https://codepen.io/fuad-zeyad-tareq/pen/jOKwRqO Never mind, putting them inside an array fixes that problem. Still trying to find out if I can demo my problem...

Haha I did not know I can get multiple elements' states in one Flip call. This did the trick!! I was avoiding absolute: true because it was affecting the wrapper which was affecting the page (but I still needed the wrapper included in the animation because of its background). Didn't realize I could just exclude the wrapper from being part of the "absolute animation". That's awesome flexibility!! Thank you for your help as always! This might be my favorite voodoo magic plugin by the way! However, I'm still having one more jump that seems to be happening in my project even after using absolute positioning for the animation. In my project I'm using an img element in place of the SVG, but I do not believe that is the reason for the issue. The first click works perfectly fine (the image enlarges to its full width as it moves to the center), but there's a "jump" (on the second click) when going back to flex-direction: row (the image "jumps" instead of animating back to its initial smaller size), it does still animate moving to the left though. I suspect this is an unavoidable layout collapsing issue (i.e. the layout collapsing will not wait for the image to animate back down to it's smaller size when the flex-direction changes) ? Side note: If Flip can calculate everything behind the scenes and animate it for you, why would you ever not use it for layout changes that you want to be animated (outside of transition-based animations) ?

So today I've had a use-case that seems to be perfect for the Flip plugin and so I started messing around with it but have been having a little bit of trouble getting it to work for a simple flex-direction toggle animation. The problem can be seen in my CodePen; the animation is perfectly fine when going to flex-direction: column, but when going back (clicking the SVG again) there seems to be a jump/skip for the SVG element for some reason. Note that I have not employed the use of the absolute positioning for the animation because that does not seem like it would work for my case since the wrapping div is also resizing when the flex-direction changes.

Hahahah that definitely sounds like you've been bitten before... been there myself a few times, and it is too easy to fall into such traps. I appreciate the offer, but I don't think it is necessary cause I do believe you on it. If performance is what you're going for (which I'd go for here myself as well), then we have no choice but to live with the ramifications of our choices. That being said though, it does not stop me from feeling like this is a problem that shouldn't be a problem... and it's probably JavaScript's fault. Don't ask me why (it's cause everything is JavaScript's fault). Haha, my bitterness here stems from the fact that I believe software in general is not getting smarter fast enough lol... like more experience in the field is fantastic, but that means every now and then my biggest time debugging is spent on something really silly like a syntax error that wasn't highlighted by the editor, an animation or a CSS change that does not get redrawn by the browser, something that works in one browser but not the other, a 3rd-party API that really sucks with asinine support, lack of/weak options for real-time notification systems, and so on. Basically all of these are issues that should be problems of the past already, but I guess that's every generation's gripe; the tools advance slower than our patience for them lol Thanks for reading my rants lol. I won't hold you off any longer. Thanks for the chat!

So I understand why you may have chosen performance over intuitiveness in this case but I still think there's room for improvement. You're right... but couldn't we exclude height changes made by GSAP itself for the element it's already watching? Would that not solve the problem of triggering the event for every single tick then? Here's an example of what I mean: Let's say you're animating the height of a span element with a paused GSAP timeline that plays on click and reverses on the subsequent click (just like the one in my example). On click, the tween changes the span element's height from 0 to 100%. So once you've clicked the element, GSAP is running the tween for the first time, GSAP has now calculated the element's initial height value and stored it for future tweens, correct? That value is initially 0, after the tween runs the first time, GSAP now expects that element's height to be 100%, after it runs again, GSAP now expects the height for that element to be 0 again, etc. Now let's say all of a sudden, the element's content changes, or something changes the element's height to 50px... the element emits a height property change event and GSAP is listening to that event, GSAP checks the height property and based on its value, it can tell that that value was not set by GSAP's last tween and thus will get flagged. Now you may say that GSAP should NOT change the height of the element back to 0 due to this flag because that will lead to unexpected and non-user friendly results, and I agree with that. Instead, I'm thinking it can use this information to output a "warning" to the console that the element being watched by GSAP has had it's height changed to an unexpected value, and could affect the GSAP animation. I'm just thinking of the top of my head, sorry if I've brainstormed something that you've probably already thought of or debunked before.

Hello Rodrigo, Thanks for the detailed explanation on this. I appreciate it. I perfectly understand this and I agree with it. What I was thinking is more along the lines of an event-based handler instead. Essentially, your library gets notified automatically when the properties change (instead of the developer having to create an event handler doing that exact thing as you suggested earlier). My guess is that there's a limitation in JavaScript or CSS that prevents this (i.e. when the element's content/properties change, there's no automatic event handler for that) ? You'd be shocked, but the reason I even ended up here is because 2-3 weeks ago (when I wrote the GSAP animation) I discovered this very thing... so I made sure to only trigger the animation once I updated the element's text (through Inspect Element) and not before to avoid triggering this issue during testing. Lo and behold 3 weeks later, I completely forgot this bug existed (and thus spent yesterday debugging a ghost problem). I don't know what else can be done here to avoid such a problem, but I sure know now not to rely on my memory since I can't even retain it for 3 weeks ?

Thanks guys! That'll definitely help for this one. However, I can't help but wonder if there's a better "in-between" solution for this kind of problem... For example, can this not be detected automatically? If the element's content changes, can we not have the tween's values be updated automatically here? I understand if JavaScript is the limit here, that's fine. I'm just a little bitter having spent a whole day trying to solve a problem that didn't exist lol I guess it could have been worse, I could have spent more than that (I knew it was working before! lol)... got really lucky I even figured it out to be honest.

Ahahaha! I think you're onto the exact cause here Jack. I believe I've come to the root cause of the issue here. However, I had to put it into a video because I'm not sure how else to replicate it. The video has audio that explains exactly what I've discovered. First Video here shows the animation working. The second video here shows how to make the exact same animation (no code changed) fail. To try to sum it up, I believe the root cause of my issue is exactly what you described above. You say "at the start of the tween" but is it possible that this "calculation" happens only the first time the tween is triggered? Because that would then explain why the subsequent animations (after the element's text content is changed) start failing (i.e. the height it calculated the first time is no longer the same as the height required after the content is changed through Inspect Element).

Just updated 3.11.2 to 3.11.3 but that didn't solve it. This CodePen is closer to what I'm trying to achieve. I seem to have it working here but not in my project. CodePen I have this exact same thing in my project but it's not working. How's that possible?! Lol

I'm doing something very similar to the CodePen and I had that exact setup working before (a couple weeks ago). Now I awake to everyone's favorite type of problem, something that used to work that is not working anymore. I'm not sure if I've added a CSS line somewhere here or there that could have tampered with this but everything seems normal to me so I'm at a loss. While the example in the given CodePen works, the one in my project doesn't (even though it's outrageously similar). Basically when the button is clicked, instead of it animating the height to auto over the duration of 1.5sas you'd expect, it simply waits 1.5s and then adds height: auto; to the element at the end. Any ideas why something like this would happen? Additionally, changing the following: .to('.test', 2, { height: 'auto' }); To: .to('.test', 2, { height: '45px' }); Works. But I don't understand why animating height to 'auto' works in the CodePen example but not in an identical code piece in my project?! Interestingly, I've seen a lot of posts on the forums asking this exact question and the answers always seem to be some form of a very simple tween example with a .to() doing exactly that, height: 'auto'. What I'm starting to suspect is that it's misleadingly simple (at least on the JS side) because there are certain elusive CSS conditions that need to be met for the animation to really work. For example, changing certain CSS in one of the parents of the element being tween'd could end up breaking the animation. Is this true? If so, can we have a list of CSS conditions that need to always be there OR should not be there (whether it's on the element itself, its direct parent, or any of its ancestors) for this animation to be successful?

Oh my lord!!! I just had to set preserveAspectRatio="none". I really thought I had tried that before and it didn't work... don't even need 2 SVGs! Great job on the DrawSVG plugin by the way guys! It's really awesome!

So I have kind of a noob question regarding SVGs for you guys. This one might be more of an SVG question than a GSAP question but since I have no idea where to start, I thought that maybe some of you SVG animation pros might be able to point me in the right direction or save me time if it isn't doable. So I was looking at this animation that I forked from one of the examples posted by you guys on the forum and I was thinking of doing the exact same animation but have it be surrounding a form. I had the genius idea of absolutely positioning the SVG from the example in the CodePen and dynamically (from the JS) set its width and height equal to the form's width/height to get this to work across all screen sizes (since the responsive form's width/height changes on different screen sizes)... the animation pros in you guys probably already know why this didn't work off the bat haha. As you can see from the CodePen, I've turned the square into a horizontal rectangle since my form has a longer width than its height on Desktop. Now since the SVG has 1 path, it fails to scale once the form's height becomes longer than its width on smaller screens. Now I thought, one solution to this problem is to have 2 SVGs; one with a vertical rectangle path for portrait screens (which I can know from simply checking if the browser's window.innerHeight() is bigger than its window.innerWidth()), and one with a horizontal rectangle path for landscape/desktop screens (as in my CodePen). That being said, my solution above seems to have some edge cases that aren't covered... for example, when responsively resizing the browser's screen, there seems to be cases where the SVG rectangle path seems to still fail to match the required width/height even though the screen's width is still larger than the screen's height (the form's width is also larger than its height in such cases). I'm just confused. I really thought the 2 SVGs solution would be it but those odd cases are really throwing me off. Perhaps I'm looking at an aspect ratio problem? Do I really need to worry about a 3rd SVG for when the screen size is close to a square as well? Lol

I am kindda new to SVG stroke animations and I was hoping that this particular animation can be customized via JS to start from a little to the right of the bottom left corner of the square (see pointed location in the image below). I was hoping that that can be done simply via changing the "50% 50%" part of the drawSVG: "50% 50%". I've tried to modify the values in this CodePen but I'm not sure I understand how the drawSVG percentages work: https://codepen.io/fuad-zeyad-tareq/pen/bGLgoPO To be clear, I'd still like the exact same animation (i.e. the borders are drawn from both directions of the origin point), just that the origin point be in a different location. Am I wrong in assuming that it can be done via the drawSVG percentages?

Awesome! That's another good tip to know. Thank you. Hahaha absolutely. To be accurate, bad quality code is a pet peeve of mine. But we must balance out how our time is spent, otherwise this happens: while(1) { // Chromium still re-writing his own code to improve it. } I'd be stuck in an infinite loop re-writing my own code to improve it ? No need to mention. Your product is a quality product, not sure I've seen a better compatibility from any other JS library out there. I'd even argue that it should be baked into JavaScript at this point... but you know what? Scratch that. Your library is too good for JavaScript. JavaScript is easily my least favorite language out there (not sure if you could tell lol) but your library makes even JavaScript more tolerable so that's saying something... Side note: I just wasted an hour trying to solve a problem that turned out was only a problem because of a... well take a look at this: if ( _square.hasClass('square1') ) _square.removeClass('square1').addClass('remove'); if ( _square.hasClass('square2') ) _square.removeClass('square2').addClass('square1'); if ( _square.hasClass('square3') ) _square.removeClass('square3').addClass('square2'); if ( _square.hasClass('square4') ) _square.removeClass('square4').addClass('sqaure3'); if ( _square.hasClass('square5') ) _square.removeClass('square5').addClass('sqaure4'); For better context: I was simply removing "square1" and appending a new "square5" on click of a button. Still haven't caught the issue? I'll give you a hint, look at "sqaure3" and "sqaure4" ? The stupid time I wasted looking into so many other things (jQuery.remove(), jQuery.append(), order of operations, etc...) not realizing it was just a spelling mistake. I even posted the problem on Stackoverflow and got 2 answers for it (that completely re-worked my simple snippet, confused me even more, and didn't explain why my simple code didn't work lol). It is days like these that make me think I should retire from this profession.

Unfortunately, while your tip worked for my CodePen: https://codepen.io/fuad-zeyad-tareq/pen/mdXyRaQ It didn't work for my current project which is similar but with like 10X the complexity. Kept having duplicating items and/or half animations even though I tried both .progress(0) and .progress(1) with and without .kill(). There's probably a logic bug somewhere... and there's plenty of crevices for that one to be hiding in lol So I opted for the next best thing for my project which is to prevent any animation restarts when there's already one happening by attaching a data API variable to the DOM element. A trick that I've also learned recently thanks to Blake the legend! It's a shame as I would have liked my button to respond to every click. But I've got a metric ton of other things I've to sort out for now... maybe I'll figure this one out some other day but that day won't be today! Can't win 'em all ya know You guys always go above and beyond so thanks for all your help getting me this far! PS: Always thought this was a paid access forum. The fact that this is free and you help everyone as much as you do (and as fast as you do!) is mind blowing! Keep rockin' Edit: Looking at my last CodePen again, it seems your trick worked when spamming the button during the first timeline of my animation but not when it's during the second timeline (Or it did, but it's not how one would want it to behave) hahaha. I suspect a separate handling needs to be added to detect which timeline is the animation currently part of (at the start of the onclick handler) and decide to progress the appropriate timeline based on that. Man my current project has so many little details just like this one that need to be individually addressed. It seems that if left towards the end, they become this big mind-boggling monstrosity you have to deal with. I think that's enough for tonight lol

Hi again Jack, I'm back with this same example. I'm having another problem now after having applied what we last discussed as can be seen in this CodePen: https://codepen.io/fuad-zeyad-tareq/pen/mdXyRaQ It seems that spamming the button unleashes all sorts of problems. Given that I do not want to prevent the user from being able to spam the button, I am unsure as to how to solve these problems. I could have swore I solved a problem just like this before but it seems I can't learn from my own mistakes ? I thought that if I initialized the t1 variable outside of the onclick event handler, that would solve it but that didn't work. Currently, it seems that spamming the button not only breaks the animations but also leaves duplicate lis all over the place (I'm guessing is due to the appended elements failing to be removed as well). Is there a way to allow the animation to be spammed but prevent it from breaking (and by proxy, it hopefully prevents the duplicate leftover lis) ?

Ah! Yes, let me re-phrase that real quick: You mentioning that overflow: hidden is still needed for my transforms (to not overflow the parent)... Better? Lol Although it seems like common sense when read like that! ?

Hahaha I know I'm a noob but thankfully I'm not THAT much of a noob @Cassie ? I appreciate you following through though. I ended up with something very simple: // Animate hiding the old posts. t1.to(_listEls, .3, { x: '-100%' }); // Remove the old posts and prepend the new posts. t1.call(function() { _listEls.remove(); // _html is the new posts HTML coming from AJAX. _ul.prepend(_html); _listEls = _ul.find('> li'); // Animate displaying the new posts. t1.set(_listEls, { x: '100%' }).to(_listEls, .3, { x: 0 }); }); You mentioning that overflow: hidden is still needed with transforms did peak my curiosity though so I had to check and yup... about the 10th parent or so of those elements has an overflow: hidden on it already so I didn't need to add that into my animation! ?

@Cassie OH MY LORD! Aren't you a gangster! I never knew transforms were this badass!!! I didn't even have to mess with padding or overflow... is this dark magic?!!!! And you say it's more performant!!! I think this even solves the next animation on the little boxes I had planned for (and was constantly thinking about at the back of my head). This feels too good to be true! I might have to take a course in transforms after this ? Oh my god my code is so much simpler too...