Jump to content
Search Community

probleme css rotateY() and opacity/position, can I use GSAP or would it be overkill ?

Demky 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,

I have a problem not related to GSAP, I don't find any solution, I asked on 3 forums (+stackoverflow) and didn't find any answer.

I already used GSAP on my webpage for a small animation and I was wondering if it could help me with this problem or if it would be overkill to use GSAP (performance/ressources).

 

I tried to document my problem on stackoverflow (if someone want to read more details) :

https://stackoverflow.com/questions/57784926/why-using-opacity-or-an-absolute-position-ruin-my-transform-rotatey180deg
 

I made a card that can rotate on Y when it's mouse hovered (everything with CSS).
the problem is that when I use css to change the opacity (svg flag) or the position of an element (text in my situation) on the back of the card, the rotate animation is buggy and got a delay of +/-1sec to display the back of the card.

/!\ the bug occur only once, the first time the rotateY is used; to do it again, you need to reload the page (F5).

 

8Pr4kw8.gif


The bug only apear in Chrome (work perfectly on firefox).

 

If I use GSAP to do the rotation instead of css, should it fix the problem or is the problem from chrome and would still be here with GSAP ?

(what would be more logic using GSAP for the rotation on Y or for opacity/text position?)

 

I made a codepen with the problem :  

-> if you remove the css classes .bottom-right and .changeOpacity there is no more delay.

 

As I said on stackoverflow, if you use the template from w3school and just add an opacity to an element from the back of their card (exemple .flip-card-back), it does the same delay problem so I don't think the error is from my code :

https://www.w3schools.com/howto/tryit.asp?filename=tryhow_css_flip_card

What would you do in my situation ?

I can't believe it's impossible to customise the back of a card that rotate ?

I don't really know if I can post my question here but I don't know where to search a solution

Let me know if something isn't clear.

 

----------------------
Edit : looking to test it with gsap to see if it work;

found this thread, will try it soon ; 

See the Pen pozWZKM by Demky (@Demky) on CodePen

Link to comment
Share on other sites

Hey demky and welcome,

 

This situation definitely shows how browsers can be quirky, especially with things like transforms (and even more with 3D transforms). I think the core of your issue boils down to the combination of transform-style: preserve-3d; and backface-visibility: hidden;. From the browser's perspective: should it pay attention to the 3D nature or the backface visibility? 

 

I was able to get it working in CSS in both Chrome and Firefox by removing the backface visibility and adding a 1px translate of the card's back in the z direction: 

 

See the Pen MWgrwJv by GreenSock (@GreenSock) on CodePen

 

But as you experienced through the hours that you spent debugging this, it would have been much easier to use GSAP from the start because it "just works" :) Also this work around is not guaranteed to work with future versions of browsers. We hope nothing will change, but there's no promise unlike with GSAP.

 

Happy tweening!

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

wow thank you, I tried to fix it for so many hours ?
I will keep the GSAP solution since I already had the CDN on my webpage. ?
 

I don't like to remove backface-visibility: hidden;

 

Maybe I don't understand the definition but it look like it perfectly fit in  this situation

Quote

The backface-visibility CSS property sets whether the back face of an element is visible when turned towards the user.

 

the translateZ(1px) is so clever ?

 

Link to comment
Share on other sites

5 minutes ago, Demky said:

Maybe I don't understand the definition but it look like it perfectly fit in  this situation

Quote

The backface-visibility CSS property sets whether the back face of an element is visible when turned towards the user.

Yes, that is true, but like I said it's the combination of that and the transform-style: preserve-3d; that I think is causing the ambiguity (and thus difference in how it's handled) across browsers. If you didn't need the perspective I am guessing that you could have used just the backface-visibility: hidden; and not the transform-style: preserve-3d;.

  • Thanks 1
Link to comment
Share on other sites

Hi @Demky and welcome to the GreenSock Forum!

 

That delay is slight and is that element with opacity being put on its own rendering layer after a snapshot has been taken. That is why it only happened on the first load so it can create that new rendering layer from the snapshot.

 

Just keep in mind that if you have one parent, in this case .flip-card-back that has a child with a CSS property that creates a new stacking context.. like opacity. That you will often have to trigger a new stacking context on the parent (.flip-card-back) also, by adding either an old CSS hack of translateZ(0), an opacity: 0.9999999, or other CSS properties that trigger a new stacking context (see the below link).

 

It is the same principle when you have an element with overflow: hidden and its child or parent has a transform or opacity triggering a new stacking context. The parent will not allow overflow: hidden to work unless you also give the parent a new stacking context with one of the CSS hacks. Then the parent will have overflow: hidden work as expected.

 

Google Chrome has more bugs than IE used to ever have. So sometimes you will have to play with the CSS properties of transform-style, and blackface-visibility. But don't forget that Chrome will also act buggy depending on the perspective used.

 

Whether that is the stand alone perspective property or even when you use the transform: perspective() function. I have found that the transform: perspective() function is less buggy than the perspective property in Chrome.

 

The GSAP animation version probably has no issues since it is using matrix3d(), i presume. :ph34r:

 

There is the CSS will-change property but that is a whole other bag of bugs. See @GreenSock (Jack's) explanation of will-change and its crazy behavior of over use. Plus Google Chrome will keep changing behavior of that so use at your own risk.

 

CSS Stacking Context triggers:

https://developer.mozilla.org/en-US/docs/Web/CSS/CSS_Positioning/Understanding_z_index/The_stacking_context

 

CSS Perspective Property:

https://developer.mozilla.org/en-US/docs/Web/CSS/perspective

 

CSS Perspective Function:

https://developer.mozilla.org/en-US/docs/Web/CSS/transform-function/perspective

 

Happy Tweening :)

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