Jump to content
GreenSock

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

rotateZ

Recommended Posts

Hello, 
I have a little problem, when I want to add a "RotateZ" to my element GSAP interprets it like a "Rotate". I would like to know if someone can help me to solve it.
You can see the problem with the code pen Url.
Sorry for my bad English.
Thank you!

See the Pen XWmgPem by Goldoknack (@Goldoknack) on CodePen

Link to comment
Share on other sites

Hey Sturmel and welcome to the GreenSock forums. Thanks for being a Club GreenSock member!

 

rotateZ() is equivalent to rotate() in this case. You're saying that you just want the inline style to use rotateZ() instead of rotate()? Or is there some other issue that I'm missing?

Link to comment
Share on other sites

By the way, you could shorten your GSAP code by using defaults and leaving out the unit:

gsap.defaults({duration: 1, ease: "power4"});

$('#start').click(function () {
  gsap.to(".flip_card_inner", {
    rotationY: -45
  });

  gsap.to(".flip_card_shadow", {
    rotationX: 90,
    rotationZ: -45
  });
});    

$('#reset').click(function () {
  gsap.to(".flip_card_inner", {
    rotationY: 0
  });

  gsap.to(".flip_card_shadow", {
    rotationX: 0,
    rotationZ: 0
  });
});    

 

Link to comment
Share on other sites

Sorry I haven't well explain. If I put into CSS rotateX(90deg) and rotate(45deg) it's ok but Gsap trigger rotate(45deg) then rotateX(90deg) and the position of my element  flip_card_shadow goes wrong.

 

Link to comment
Share on other sites

That's an order-of-operation thing. GSAP very intentionally delivers a consistent order of operation. Trust me - this is a GOOD thing :) If you need an explanation, let me know.

 

To resolve your issue, you can just animate the "transform" to a string value like: 

transform: "rotateX(90deg) rotate(45deg)"

Does that give you the effect you wanted? 

 

For the record, it's almost ALWAYS better to use the individual components with GSAP, like rotation, scaleX, scaleY, x, y, etc. with numeric values because it ensures there's no ambiguity and it's faster. With string-based "transform" values, it must apply that to the element and then read back the computed style and parse the matrix() or matrix3d() which is an extra few steps. It's not a big deal, but I'm obsessive about performance and accuracy. So the only time I'd recommend using a string "transform" like this is for your scenario where you're depending on a non-standard order of operation. 

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

More info on why this is the case: 

 

  • Like 2
  • Thanks 1
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.

×