Jump to content
Search Community

Stagger is broken on latest update

wpsoul test
Moderator Tag

Go to solution Solved by GreenSock,

Recommended Posts

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 :)

  • Like 2
Link to comment
Share on other sites

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

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

  • Like 3
Link to comment
Share on other sites

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

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 seconds
When 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

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

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

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

  • Solution

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.

  • Like 2
Link to comment
Share on other sites

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 account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...