wpsoul Posted September 7, 2022 Share Posted September 7, 2022 I think that there is bug in all stagger effects in latest update. I checked on previous version and it's fine As you see, only first element is animated (sometimes all animated but not finished and it has step effect). P.s better to edit on codepen to see what I mean See the Pen rNpoORy by igor-sunz (@igor-sunz) on CodePen Link to comment Share on other sites More sharing options...
wpsoul Posted September 7, 2022 Author Share Posted September 7, 2022 After some testing, I found that problem is in cases when element has css transition property. Why do this affect stagger? Previously it was not a problem. Link to comment Share on other sites More sharing options...
GreenSock Posted September 7, 2022 Share Posted September 7, 2022 That actually makes a lot of sense. You should NEVER apply CSS transitions to the same properties that you animate with GSAP because not only is it terrible for performance, but it'll totally get in the way. Every time GSAP sets the property (60 times per second usually), the browser is like "NOPE! Sorry, I'm gonna gradually apply that change instead..." So a .from() tween relies on IMMEDIATELY setting the values. The CSS transitions are preventing that. So then when the tweens actually start and record their start/end values, they're thrown off by the CSS transitions that muck it all up. See what I mean? In short: nix the CSS transitions 2 Link to comment Share on other sites More sharing options...
wpsoul Posted September 7, 2022 Author Share Posted September 7, 2022 4 hours ago, GreenSock said: That actually makes a lot of sense. You should NEVER apply CSS transitions to the same properties I don't apply css transitions for the same properties. I apply transition: all 0.4s (for example). And it's for applying hover transitions on the same block and this was working early. Does it mean that GSAP checks also hover state now? In css, only Box-shadow effect is applied on Hover. Does it mean that we can't add any css effects on the same block now? And why it's not working only on staggers? Link to comment Share on other sites More sharing options...
Cassie Posted September 7, 2022 Share Posted September 7, 2022 Hey there! This is applying a transition on *all* properties. So that's going to include any properties being animated with GSAP! This says, whenever anything changes on the element I've applied this to, make that change last 0.4s Quote I apply transition: all 0.4s So when GSAP tries to move the elements, CSS is overriding it. We recommend just using GSAP (we always have, because issues like this arise when you mix CSS and GSAP animations) But of course, you can still use CSS hover effects, you just have to make sure you're not animating the same element and causing conflicts. Here's a simplified demo See the Pen JjvYZqB by GreenSock (@GreenSock) on CodePen 3 Link to comment Share on other sites More sharing options...
wpsoul Posted September 7, 2022 Author Share Posted September 7, 2022 46 minutes ago, Cassie said: Hey there! This is applying a transition on *all* properties. So that's going to include any properties being animated with GSAP! This says, whenever anything changes on the element I've applied this to, make that change last 0.4s So when GSAP tries to move the elements, CSS is overriding it. We recommend just using GSAP (we always have, because issues like this arise when you mix CSS and GSAP animations) But of course, you can still use CSS hover effects, you just have to make sure you're not animating the same element and causing conflicts. Here's a simplified demo I understand that css property can affect animation. It's not my problem. My problem is that stagger animation didn't finish even in fact that css has no any applied css transform properties, it has only transition easing. I updated my codepen, I included also another gsap.from but without stagger. As you see, problem is only on stagger block, blocks without stagger property has no problems in finishing animation. Link to comment Share on other sites More sharing options...
Cassie Posted September 7, 2022 Share Posted September 7, 2022 Quote My problem is that stagger animation didn't finish even in fact that css has no any applied css transform properties, it has only transition easing. Yes - this is the problem. The transition easing is applying a duration to any state change on that element. This isn't a GSAP issue though. As Jack said, it makes logical sense. If it was working before you got lucky but it shouldn't have been. Here's a slowed down example of what's going on. There's a 4s transition applied in the CSS. GSAP tries to *immediately* move the boxes to their 'from' position GSAP can't immediately move the boxes - instead the CSS transition eases those boxes into place over the 4 secondsWhen the GSAP animations try to record their start/end values, the CSS transitions are busy animating the elements so the start/end points aren't correct. See the Pen eYrpPEB by GreenSock (@GreenSock) on CodePen this is saying 'I want the duration of any movement on the box to be 4 seconds long' .box { transition: all 4s } Link to comment Share on other sites More sharing options...
wpsoul Posted September 7, 2022 Author Share Posted September 7, 2022 I still think that it's bug in latest update Here the same codepen in 3.10 version See the Pen PoePxPq by igor-sunz (@igor-sunz) on CodePen It's working, stagger completes animation as it should. Why? Do you mean that all previous years it was wrong and now it's correct? How about situations when I need hover transform effect on animated blocks? Link to comment Share on other sites More sharing options...
Cassie Posted September 7, 2022 Share Posted September 7, 2022 Yeah, I understand that it's frustrating that it worked before and now doesn't. We're sorry about that. It's definitely annoying when you have to rewrite things. But the behaviour now makes sense. I understand entirely why it's happening. I'll leave this thread as it stands now and let @GreenSock decide whether it's a bug that needs fixing or not. The guidance has always been not to mix CSS transitions/animations and GSAP on the same elements like this. Applying'transition: all' is also pretty bad practice across the board, I've had nothing but headaches and animation bugs to deal with when I've inherited codebases that don't specifically define the property they're transitioning. https://www.pno.dev/articles/dont-use-the-all-keyword-in-css-transitions/ And as I said, there are plenty of ways around this, using a container as in the demo I linked to above or using specific declaration if you're animating a different property in CSS or GSAP. transition: background-color 0.4s I'm sure Jack will look into it in more detail and see if it needs fixing. Thanks for letting us know about it. Link to comment Share on other sites More sharing options...
Cassie Posted September 7, 2022 Share Posted September 7, 2022 This is the correct way of handling this - separating out the CSS and GSAP animations to different elements and making sure you're using specific declaration to minimise possibilities of conflicts. See the Pen JjvYZqB by GreenSock (@GreenSock) on CodePen This is a problematic approach - notice how even with the old version of GSAP, the stagger tween and the hover conflict with each other. See the Pen yLjYQdx by GreenSock (@GreenSock) on CodePen Link to comment Share on other sites More sharing options...
wpsoul Posted September 7, 2022 Author Share Posted September 7, 2022 I understand situation if we have transform: translateX in css and we animate the same in GSAP, but it's not my situation. Not critical problem, but it's strange that it's worked early. 1 Link to comment Share on other sites More sharing options...
Solution GreenSock Posted September 8, 2022 Solution Share Posted September 8, 2022 Yes, this is NOT a bug - it's related to the new revert() functionality which gives tweens a more thorough "cleaning". It was necessary to tap into it for from() and fromTo() tweens to clear out the "from" state. Otherwise, the recorded inline styles would get contaminated and reverting wouldn't work for from() and fromTo() tweens. In previous versions, the inline styles were forced during the whole tween including the initial state defined in the from portion. But now with revert() functionality baked into GSAP, it had to go a step further and wipe out the inline styles that were added by the initial state to make sure it was all recorded properly when the tween starts running for the first time. Again, not a bug although I understand why it looked that way to you. This update actually exposed an important problem in your setup - those CSS transitions were definitely hurting you even if you didn't realize it. 2 Link to comment Share on other sites More sharing options...
Recommended Posts
Create an account or sign in to comment
You need to be a member in order to leave a comment
Create an account
Sign up for a new account in our community. It's easy!
Register a new accountSign in
Already have an account? Sign in here.
Sign In Now