Jump to content
GreenSock

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

Perspective problem with v1.18.3

Recommended Posts

Hi, I have a problem with a version 1.18.3

 

Here is a codepen with 1.18.3 in action

 

and here is a same code with 1.18.2 in action

See the Pen reZJKE by anon (@anon) on CodePen

 

First I have tried to fix my code, which was working before and later i have realized that I have updated TweenMax version. After switching to 1.18.2 everything works fine as before.

 

Is something changed so I need to change my code or this is a bug? Thanks!

See the Pen PNdQdO by anon (@anon) on CodePen

Link to comment
Share on other sites

Hello tronyx, and Welcome to the GreenSock Forums!

 

This is happening due to not specifying the pixel units for perspective.

 

Here is your example working with 1.8.3:

 

See the Pen qZMoNr by jonathan (@jonathan) on CodePen

 

When pixels units are omitted perspective wont work as far as in the browser. Something is happening in 1.8.3 with perspective, that it is not adding the pixel units when it is given as a number and not a string. ( px )

 

So you have this: 

TweenMax.set('div', {
  perspective: 70
});

So it would become this as a string with px:

TweenMax.set('div', {
  perspective: "70px"
});

Using transformPerspective on the <span> instead, that works without px units as a string?

 

See the Pen oxPqgZ by jonathan (@jonathan) on CodePen

 

On a side note.. anytime you rotate .. you should add transformStyle: "preserve-3d" so the browser knows what your intent is regarding the 3D space.

 

Also keep in mind that the CSS perspective property is still listed as experimental regarding the CSS spec. And there will be instances when you add perspective to parent of the element you are animating and no perspective will be applied due to not using the z axis:

 

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

 

That is weird why that is happening with only perspective without units specified on the <div> and not when transform-perspective is used on the <span>?

 

Jack and Carl will have to look into that to see why the px is being omitted for numerical perspective values!.

 

:)

  • Like 1
Link to comment
Share on other sites

Hi Jonathan, thank you for your quick response.

 

Sadly, this soution works on previous example, but on real code it doesn't.

 

Here I have created real problem, with 1.18.3 and using string as a prespective value.

 

See the Pen QNVrdE by anon (@anon) on CodePen

 

If I use numeric value it still has a bug, but somehow different.

 

If I use 1.18.2, no matter which value I set for perspective (numeric or string) it works perfectly fine.

 

I'm still not sure if that's some bigger bug or I'm doing something wrong, but in 1.18.2 works just fine :)

Link to comment
Share on other sites

That is because you are trying to apply perspective and or rotationX on an SVG element. SVG 1.1 does not support CSS 3D transforms, thus will not support perspective due to that not being supported in the SVG spec.

 

Your previous example from above was animating a DOM element, not an SVG element. So in order to use 3D transforms you need to animate a DOM element, not an SVG element. You can always wrap your SVG element with a DOM element and use 3D transforms on that instead.

 

You can still use rotation since technically that will rotate in 2D.. But using rotationX or rotationY and perspective on SVG elements will not work due to the SVG spec stating that CSS 3D transforms will not work. You have to wait until SVG 2.0 supports CSS 3D transforms. Basically rotationX and rotationY when rotated intersect within a 3D planes z-axis.

 

Some webkit browser might allow 3D transforms on SVG elements for a time, but that is not allowed in the SVG spec. And that non-standard behavior is being removed and will be removed eventually in webkit based browsers. Firefox honors the SVG spec, that is why CSS 3D transforms do not work on SVG elements in Firefox. Since Firefox honors the SVG spec in this regard.

 

Also keep in mind anytime you animate with CSS transforms (2D or 3D), you get better performance when using position: relative or even better using position: absolute on the element being animated, since when animated the element will animate outside the flow of the document.

 

:)

  • Like 3
Link to comment
Share on other sites

Ah, thank you very much, great answer! I will keep that in mind!

Though again, I am not sure how that actually works fine with 1.18.2 in every browser, even in IE10 :)

 

Here is the same code with 1.18.2 

See the Pen QNVBPw by anon (@anon) on CodePen

Link to comment
Share on other sites

GreenSock's Jack will have to look into why 1.8.3 will not add the CSS perspective property if it is a number and not a string with px?

 

I'm sure he will see this forum topic and see whats happening in 1.8.3

 

Jack is always great on fixing any weird browser behavior that users find! That is what makes GSAP so awesome!

 

But in my own personal projects i always just wrap my SVG elements in a DOM element so i can do both CSS 2D and 3D transforms without worrying about the ever growing SVG spec.

 

:)

Link to comment
Share on other sites

Yes, there is a problem with perspective property if it is a number and not a string. In 1.18.3 that property is applied, but if I set numeric value of 70, it will apply css value of 700px.

 

 

Also, what I'm trying to point to, there is a second problem, maybe connected to first one. If you look at my two previous examples, I have set perspective property as a string in both, and when I inspect code perspective have a value of 70px. So far soo good.

 

But in 1.18.3 rotated element have following property:

matrix3d(1.2, 0, 0, 0, 0, 0.848528, 0.848528, 0, 0, -0.707107, 0.707107, 0, -11.9098, 9.27076, 0, 1)

and in 1.18.2 (which is correct)

matrix3d(1.2, 0, 0, 0, 0, 0.848528, 0.848528, 0, 0, -0.707107, 0.707107, 0, 0, 0, 0, 1)

I hope that now is more clear. Also, sorry for my bad English :)

Link to comment
Share on other sites

Thanks for the response, Jack.

 

Yup, seems like 1.18.4 will fix both problems! Looking forward to it!

  • Like 1
Link to comment
Share on other sites

GSAP 1.18.4 is officially released, so feel free to update your files/links. The only caveat is that the NPM registry seems to be having difficulty updating (though I published this morning) and still shows 1.18.3 but I reached out to their support team and hopefully will hear back. But our zip downloads, Github repo, and the CDN links are all updated to 1.18.4 now. Enjoy!

  • 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.
×