Jump to content
GreenSock

Search In
  • More options...
Find results that contain...
Find results in...
cstodor

Converting CSS transforms to GSAP and getting weird positioning

Go to solution Solved by GreenSock,

Warning: Please note

This thread was started before GSAP 3 was released. Some information, especially the syntax, may be out of date for GSAP 3. Please see the GSAP 3 migration guide and release notes for more information about how to update the code to GSAP 3's syntax. 

Recommended Posts

Hi there,

 

I'm converting a CSS animation to GSAP, and I'm getting some weird positioning after conversion.

Can anyone tell me what am I missing here?

Any help would be appreciated.

 

 

 

 

See the Pen XdOyQw by cstodor (@cstodor) on CodePen

Link to post
Share on other sites

Thanks for the demo. It's very cool. Haven't really seen anything like it and I'm not exactly sure what you are doing to pull it off.

For me it looked great in Safari. In Chrome there seemed to be a little gap at times, and FireFox was pretty horrible.

 

 

It would really help if you could reduce it to just a single element and then isolate the part of the animation that isn't working correctly.

However, my guess is that this has very little to do with GSAP and more to do with rendering glitches in the browser. 

  • Like 2
Link to post
Share on other sites

Also do you have the CSS only animation example for reference?

  • Like 1
Link to post
Share on other sites

I'm aware of the rendering problem, but I forgot to say that I've commented out the code that was causing the issue. ( JS line: 7-11 )

That code is the conversion of the CSS found at line 2-21. If you remove the comments, you will see that it has a different outcome.

 

The original Pen with CSS only animation can be found here: 

See the Pen EKOoyW by golle404 (@golle404) on CodePen

 

Thank you for your help!

 

 

Link to post
Share on other sites

I am seeing the same animation and behavior with the CSS only animation.

 

I tested on Windows 7 (64-bit) in latest Firefox, and Chrome

  • Like 1
Link to post
Share on other sites

I can confirm what Jonathan is seeing. Same behavior in Win7 FF and Chrome for the CSS version. (tested Win7 and Win10)

 

Win7 IE11: neither version works there. The CSS version shows one cube face and just a line for the other two. The GSAP version is showing only one face of one cube.

 

Win10 Edge: The CSS version works, but the cubes are no longer close together. The GSAP version works , but the same animation behavior from FF and Chrome is present.

Link to post
Share on other sites

I think you got me wrong. to see the issues that I was referring to, you need to remove the comments from line 7 and 11 of the JavaScript code.

Link to post
Share on other sites

Just to clarify @cstodor when i tested i tried both CSS and JS versions .. and in the CSS original and the JS version, i see the same behavior.  :(

 

@Craig IE11 wont work in both due to not supporting transform-style: preserve-3d

Link to post
Share on other sites

@Craig IE11 wont work in both due to not supporting transform-style: preserve-3d

Yep - understood. I just threw that out there so anyone else reading this would know not to expect anything to work correctly in IE11.  ;-)

Link to post
Share on other sites

If I understand your question correctly, the problem is simply that you were defining transforms in non-pixel values (ems in your case). You can use "%" or px (the default). There are several reasons for this:

  1. Performance
  2. The nature of matrices simply won't allow for non-pixel values. We could certainly convert the units into their px-equivalents but that wouldn't be a "true" simulation because for example if you used "vw" and then after the transform was animated to its end value, you resized the window, it wouldn't alter the position. 
  3. Consistency. We store numeric values in the _gsTransform object which makes it easy for folks to look up the current value at any time, but if we start making that number relative to arbitrary units, it creates an inconsistency and could cause a lot of headaches for folks. In other words, if element._gsTransform.x is 50, does that mean 50px or 50em or 50vw, etc.? If it's always px, that simplifies things quite a bit. 

Again, the biggest reason has to do with performance - we could apply a bunch of logic to simulate/accommodate other units but it's very rare the developers have requested this over the years and I'd rather not cram all the extra logic in there and force everyone to pay the performance cost. 

  • Like 4
Link to post
Share on other sites

Thank you for your accurate answer @Jack! It makes much more sense now.

So, I will need to convert the 'em' units to either pixel or percentage values to get the result that I'm looking for.

 

Can I ask one, possibly silly question... what happens if I would like to animate elements on a website which uses 'rem' and 'em' units by default (like Bootstrap 4), and considering that I use pixel values in the Tweens, would that cause any inconsistency in the design between mobile and desktop devices?

 

Cheers,

Link to post
Share on other sites

It shouldn't cause any problems if the starting values (set in the CSS) are based on ems or rems because the getComputedStyle() values that browsers report are almost always in px anyway. As far as whether or not it would cause inconsistencies in the designs on mobile devices or something, I can't really think of anything that would be problematic but I'd recommend doing some tests and let us know if you run into any issues. We'd be happy to help troubleshoot a codepen example or something. 

Link to post
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.

×