Jump to content
GreenSock

Chromium

ShockinglyGreen
  • Posts

    33
  • Joined

  • Last visited

About Chromium

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

Chromium's Achievements

  1. 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!
  2. 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
  3. 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?
  4. 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.
  5. 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
  6. 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) ?
  7. 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! 😂
  8. 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! 😁
  9. @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...
  10. The beautiful combination of white-space: nowrap and clearProps works like magic. But I do have a follow-up question... so the example in my CodePen was for very simple HTML elements but what I'm applying these animations for is the following elements (please see the following GIF): For contextual purposes, the animation above is being applied to each white rectangle element simultaneously. The animation is also a bit slowed down for better visual debugging. As you can see, the content of these elements is a bit more rich than the elements in my simpler CodePen example. And so, this adds some complexity to my animation. While awesome for my CodePen sample, due to the removal of white-space: nowrap at the end of the tween animation (once the tween finishes and runs clearProps: 'margin-left, white-space, overflow'), you see this height jump at the end. So I have the following 2 questions: Is it possible to animate the removal of white-space: nowrap so that the height jump happens a bit more smoothly? Is there a better way you could think of animating this? Haha I know the last question is a bit of a broad question fishing for suggestions... but given the fact that each white rectangle element that's being animated can be any unknown height (due to its content), I see no other options than to do it this way. Lol
  11. white-space: nowrap!!!! Dang it! You mean to say that I didn't have to do all these height calculations all this time 😂 AND it solved my choppy CodePen animation!!! 🤦‍♂️Now that's just rubbing salt on the wound! Lol Thank you for the 1-liner @PointC! Now that solves 3 out of the 4 questions! So now I'm simply doing: t1.set(_listEls, { 'white-space': 'nowrap', overflow: 'hidden' }) At the start of my animations. So this question still remains: This question assumes that I don't know what inline styles were added by the timeline.
  12. So I've found myself almost always having to do the following (as can be seen in the CodePen) for responsive elements that don't have a fixed height: t1.set(_listEls, { height: _listEls.outerHeight(), overflow: 'hidden' }) Whether it's with .set, .from, .fromTo, etc. At the start of every animation that involves an element's width or left/right margins. This is so as to simply avoid the element's responsive handling from triggering and overflowing/increasing in height as it shrinks (during the animation). That being said, I am wondering if: Is this the best way to go about this or am I missing a much simpler way? While this addresses the responsiveness of the element itself, it doesn't address the responsiveness of child elements from doing the same thing. Is there another quick GSAP trick (inline-style perhaps?) that deals with this particular problem that I'm sure is common when animating width/margins? Is there a way to remove those specific styles from the element on animation completion without removing any potential other inline styles on the element? Side note: Is the animation in the CodePen lagging just for me?
  13. Haha yes, while that might be my end goal, the getting there is not limited to my own explanation of it. I'd like to get there in the simplest way that gets me there even if that's a different way as long as it will still allow me to efficiently achieve my end goal. Thank you for this suggestion. I think this might be a bit overkill for what I'm trying to achieve. Hopefully, there's a simpler way. Let me explain my end goal further below. Let me explain what exactly I'm looking to achieve (from start to end) and perhaps you can point me to the best way to go about it: Animate _listEls (as is already done at the start of the timeline in my CodePen example). Remove _listEls and prepend new _listEls (as is already done in the t1.call in my CodePen example). Re-animate the entrance of the new _listEls from the step above (this is where the .set followed by probably a .to would come in). During all of the above, I'd like to also animate a whole separate element in the DOM (let's call it _el2). So ideally, _el2's animation (or series of animations) total duration will span the duration of the animations of the elements from steps 1-3. I thought that the simplest, cleanest, and most concise way to go about all of these animations is to keep them all under the same timeline. But as you've explained, it seems that due to step 2, that is impossible. So what's the cleanest way you'd suggest to go about this? Edit: Maybe I'm overthinking this (as I usually do). Maybe I'll just finish the _listEls animations inside of the t1.call like you suggested (speaking of... doing t1.set inside the t1.call after removing and prepending the HTML seems to work in my dev environment but not in the CodePen example for some mysterious reason). And have a whole separate t2 timeline for the other element (_el2) that will run the other animations simultaneously to t1. I'm assuming this is the simplest and most elegant way of going about this.
  14. Hi Jack, Thanks for the explanation. I figured it's a logic issue because I'm a little unclear about how the timeline works here. Looking at your code it seems all you have done is make the .set block into its own tween and move it inside of the t1.call. However, I am hoping there's a way to do the .set on the t1 timeline so I can continue animating these elements (and possibly other elements within the same timeline as well) ? I guess where my confusion lies is that I thought the t1.call happens in logical order in the timeline, so when I did t1.set, I expected that to happen after the t1.call is done with whatever it's doing (meaning remove and prepend the new elements and update the _listEls with the new selector accordingly). But it seems that is not the case... does the t1.call return before whatever is inside it is executed? If that is so, then is there a way to make the timeline wait for the t1.call to finish first (or is there a better way to go about this that I'm missing) ?
  15. The CodePen is hopefully self explanatory. I'm going to lose my mind over why the second t1.set is not working. Also, assuming we do get it working, ideally, I'm hoping that there won't be a flash of content before the 'margin-right' is applied by the t1.set. Side note: any idea why it's choppy for the first 75% of the animation?
×