Jump to content
Search Community

x/y/z vs translate? Any difference?

jesper.landberg test
Moderator Tag

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

Hello jesper.landberg and welcome to the GreenSock forum!

 

Basically they would do the same thing. But by using "x" instead of "transform", is that by using " x" you guarantee that your translate will be animated cross-browser.

 

In your example above, depending if it is a WebKit based browser. You might need to add the prefix "-webkit-" to the "translate" property. So then you would have to write multiple tweens with different transform values, or use some browser check if statements. GSAP does all the heavy lifting behind the scenes, making sure the right CSS property gets applied depending on the browser.

 

So in the long run using the GSAP shorthand x,y, z will allow you to write less code, ensure cross browser compatibility, and make your life easier.

 

Does that make sense?

 

:)

  • Like 2
  • Thanks 1
Link to comment
Share on other sites

Great input so far, but I wanted to add another aspect that I think is very important...

 

Whenever you define a transform as a string like transform:"translateX(50px)", it must apply that to the element and then read back and parse the matrix() or matrix3d() that the browser creates. Why? Because that string could have any number (and order) of values in it, like transform:"translateX(50px) rotate(40deg) scale(0.5,0.5) translateY(100px) rotate(30deg)". Remember, according to the CSS spec, order of operation is important and you can string together a bunch of stuff (notice my example has two different rotate() values). All of those get mashed together into a matrix() or matrix3d(). My point is that it's a lot more work that way.

 

Using GSAP for transforms gives you a consistent order-of-operation which has many benefits, one of which is that we can further optimize for speed. So if you define x:50 instead of transform:"translateX(50px)", GSAP can just grab that one value and handle it independently without all the extra calculations. In short, there is a definite speed benefit from using our transform component aliases like x, y, z, scaleX, scaleY, rotation, etc. 

 

Another bad thing about defining transform:"..." is that you can lose rotational precision. The matrix that results from a rotation of 360 is the same as the one that results from 720 and 0 and 1440. It's impossible to extract the rotational data accurately when it goes beyond a full rotation. This has nothing to do with GSAP - it's the nature of matrices. However, if you use GSAP's built-in aliases, you always get perfect precision no matter how far you exceed 360 degrees in any direction. 

 

I'd strongly recommend ALWAYS using GSAP's built-in aliases for transforms unless you need a non-standard order-of-operation (which is very rare). 

  • Like 5
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...