zachschnackel

We're using GSAP quite extensively in http://rhinogram.github.io/rhinostyle/ without any 3rd party libs to control how we interact with it. You can also check out this branch https://github.com/rhinogram/rhinostyle/tree/zach/modal-append-example that is an update to how we deal with Covers and Modals (that need to append to the body) by using https://github.com/jpgorman/react-append-to-body

Thanks a lot!

No worries at all! I really appreciate you taking a look at that. And yep, working ? now. Thank you very much!

Hi, I was having some trouble with the latest GSAP (1.20.1) and the TextPlugin -- not showing any errors, just not actually doing anything. I also tried the referenced CodePen (the official example) and that doesn't appear to be working either there when I switch out for the latest GSAP. Any thoughts? Maybe a build issue? Not sure if other plugins are also impacted.

Whoa, looks like the latest beta is tagged 1.20.0 -- maybe getting some extra goodies in there? ?

? Thanks for the update. I think we'll probably hold off until the official release, but it's great know this will be in there soon. Thanks again for looking into this so quickly!

Hey @Carl, ok thanks - fair enough. I know this is the dreaded "next question" that you get too often and hate answering, but was there a target date set for the next release? Thanks!

Hi, Is there a way to install GSAP from npm still that has the latest code? Going on https://github.com/greensock/GreenSock-JS only shows the latest release. Thanks!

That did it! Thank you very much for looking into this. Yeah, the whole reason we went down this weird route was due to that other forum post I linked having that weird, jittery bug on resize. Chrome definitely has its quirks, but once again, GSAP to the rescue! Have a great night!

Hi, Thank you very much for all the help with I ultimately decided to give this another shot a different way -- which was re-using the existing HTML structure we have in our app and taking the class-based animations and putting them in GSAP. What I've noticed (from the CodePen URL) is that the `min-width` property is not resetting back to 100% in IE11 and Edge. If you try that demo in Chrome, Safari, or Chrome, things work as expected, but it stays at that "complete" value I have in the tween. Any help would be great appreciated as this doesn't suffer from the resize-jitters the other example I had did. Thanks!

Hey everyone - thanks for sticking with me on this. Yeah the jitteriness with the buttons and message is part of the issue there; so that's entirely based on rem? Thanks @Carl for mentioning the Modifiers plugin, that's super useful (but yeah I guess doesn't really help out here). Another dev was talking to me about this and mentioned that when he was originally working on this panel system in CSS (I'm re-doing it in GSAP) anything he did that transformed anything but 100% would cause blurry text in Chrome; so since I'm seeing something similar, I wonder if this is outside of GSAP.

Thanks for the tip about using x/Y Percent. Unfortunately it appears to be an issue with flexBasis as removing those properties does not cause the jitteriness on resize. Is there a way onUpdate to force the calculation of the container to always be the lower-end of the pixel calculation for the container it is interacting with? It's just so odd that this is only an issue in Chrome (59).

Hi @Jonathan appreciate the reply! I tried both the rotation and z properties like you mentioned, but that didn't make a difference. I've noticed that if I translate the wrapper by a whole value (like 100%) the bug is not there; it appears only when I'm interacting with calculations that would render a subpixel.

Hey Blake, Thanks for taking a look. I've made that pen public. Are you on a non-retina screen by chance? We were noticing the issue when viewing in debug mode https://s.codepen.io/zslabs/debug/jmRYLR and both the convo and profile panels were open (on desktop view so you can see them side by side). In the compute panel within Chrome, the text was blurry on decimal pixel values of the surrounding `.convo-wrapper` and `.profile-wrapper` We're seeing lots of "jittering" with the message and button elements. I did just upgrade to v59 and restarted, but still there.

Hi all! I've created a CodePen that shows off a panel animation I'm working on for the backend of my app (obviously simplified for demonstration). If you click through with the buttons on the top (have a large screen so you can see the convo view slide over with the inbox view still there) you'll notice I'm animating the panel widths with flexBasis. On resize EVERYTHING is jumping around when Chrome hits half-pixels (look at the sample convo and button, as well as the pseudo selector text)... but it's only Chrome from what I can tell. It almost seems like it's an issue with how the values are calculated, but I'm unsure if this has anything to do with GSAP. I've tried `will-change: transform`, the typical `backface-visibility` tricks, and even setting `force3d: true` in the animations, but it's just not working. Any tips on how to avoid all the jitters would be much appreciated. I'm also noticing some bluriness on non-retina screens. Thanks! Try to look at the demo in debug mode.

Ah! They do not -- they set them back to their original values, but still inline them. So -- what I did was run `TweenMax.set(panelSelectors, { clearProps: 'all' });` to make sure those are 100% clean before setting the progress of other timelines. Thanks for your help!

Thanks Blake - I'll go down that route and see if I have anymore issues with that. Am I correct in assuming both `clear()` and `kill()` will remove the inline style attributes after running `seek(0)`?

It's almost as-if some of the checks around the `progress()` are being checked twice before GSAP has enough time to update. Since my resize listener also runs during requestAnimationFrame (as does the GSAP ticker) I wonder if things are getting confused in there...

Hey Blake - I think I have http://codepen.io/zslabs/pen/d15a0b4bad1c6ed25ac327db68d67606?editors=0011 working about 99.9%, but for some reason while re-sizing and interacting with the panels, the resize listener gets in a weird state where it will be "off" what it should calculate to. It's a bit sporadic, so I'm not sure if it's an issue with `progress()` (if it's asynchronous) or what, but something gets confused after a number of interactions.

Those examples are awesome! Thank you as always for the support and willingness to help explain. Have a great day! For anyone else that references this later, you can follow along in that pen, but Blake's examples may be a bit more straight-forward to consume.

Hey Blake, thanks for the reply! That's really clever about killing and rebuilding timelines. I'll give that a shot and report back. Thanks again!

Hi all! In the attached CodePen, I have a reduced test-case of a UI I'm working on. On desktop-view (768px and higher) if you click the "Open Convo" button, the Inbox and Convo panels will both be on the screen by manipulating their `flex-basis`. If you then click the "Open Profile" button (enabled when you click the "Open Convo" button on desktop, you'll see the entire `.app-panels` transform over to show that area. I have a slightly different UI if you interact with the panels on mobile (767px and lower --- do a refresh to interact with mobile and just drag the window in smaller so the other timelines run don't conflict <-- one of the things I'm trying to fix). If you go through the same steps as mentioned above, you'll notice just the `.app-panels` div transforms to show the full-width version of each panel within it -- which all works fine. Now -- refresh and start with the desktop-view again and open the Convo. What I'm doing in the resize listener `optimizedResize.add()` is checking if the convo desktop timeline has been run by using `progress()` and if it is complete and on-resize if it's in a mobile-view, I want to set the progress of the desktop timeline back to the beginning and then set the progress of the mobile timeline to 1 (or finished). I have a `clearProps` helper in the `onReverseComplete()` callback of the desktop timeline, but the ending prop styles of the desktop timeline still remain, so it messes up the mobile-view. I know that's kind of a cluster-f*ck to throw at ya, but hopefully that's a good enough explanation. I'm not sure if it's an issue with editing the state of GSAP timelines within a resize event or if it's the nature of calling the `progress()` function of two timelines that could override each other. Let me know if you need anymore clarifications. Thanks for checking this out!!!

Really appreciate the thorough explanation around this! I dug into this and also found that if I perform a `set()` with the display property first, THEN do the rest of the tween after that everything also works correctly. I'm certainly always a stickler for performance, so if you've found any regressions in your update, maybe something to note in the docs about that browser quirk and the workaround I mentioned (just food for thought). Thank you for always having our back and for continuing work on such an awesome platform. Hope you have a great weekend!

Hi all! I'm noticing an issue with GSAP merging in transform properties originally formed in the CSS. I've attached a CodePen to show the issue. In Chrome, you'll see that both Dropdowns align to the center as intended. But in Firefox, IE11, and Edge -- it looks like the transform matrix that is generated is not including the calculated width of the dropdown component when transitioning. We can't use fixed widths (in the example that works) for a certain application, and found it really odd that only Chrome and Safari are handling this alright. Let me know if you need anymore info. Thanks as always!

I think I had some conflicting resize listeners that was firing off the progress timer that was getting in the way. Making this a more vanilla test worked as it should. Thanks both for helping!