x attribute not overriding css tranform

[manny2003]

Hi,

I am very exited about GSAP so I just started to discover it playing around. Congratulation to all the staff!

There is a thing that I cannot understand and I am wondering if this could not be a bug.

 

When you set a transform CSS value (ie transform: matrix(1,0,0,1,0,0); ) through a CSS stylesheet and then you try to use GSAP to tween a movement to a different position, the CSS is not overridden since the transform is only set as an attribute and not also as a CSS inline style property.

I know that I can use TweenMax.set function to set the transform value instead of using CSS, but sometimes this could be inconvenient and overriding a must.

 

Is there anything that I have not understood on how to correctly use GSAP for this purpose?

 

Many thank!

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

[GreenSock]

Welcome to the forums & GSAP, @manny2003! I think you'll like it around here.

 

By default, GSAP always applies transforms to the "transform" attribute of SVG elements because:

• That's what the SVG spec calls for
• They're more predictable and reliable across browsers. There are various quirks when transforms are applied via CSS styles in Safari, Chrome, Firefox, and Edge (different problems with each). We originally applied things to CSS by default and then later switched to the "transform" attribute in order to normalize behavior and conform with the spec. 

The main problem you're facing in that situation is that you end up with competing sources of truth. In other words, if the CSS has one value, and the transform attribute has a completely different value, which should the browser render? Some browsers prioritize CSS, while others prioritize the transform attribute. Yuck, I know. 

 

That's one of the reasons we always recommend setting values via GSAP whenever possible. Specifically:

1. It works around browser bugs
2. It allows GSAP to cache the values to improve speed
3. It ensures rotational accuracy, especially beyond 360 degrees. GSAP can parse existing CSS that's applied to an element (it must do this to record starting values), but the browser always reports computed styles as matrix() or matrix3d() in which rotational values can get very muddy and it's actually impossible to decompose in a way that always discerns the original components. For example, rotations of 0, 360, and 720 would all result in the same matrix. When you mix in 3D stuff, it gets way more complex, like a rotationY of 180 would be the same as a scaleX of -1. In fact, there are infinite options and ways to decompose the values, and they often don't really match what went in originally. So when you set the via GSAP, they get locked in, cached, and always remembered so that it's perfectly accurate every time. No messing with decomposition, parsing a string of 16 values and trying to pull out the data, etc. 

Does that clarify things?

 

Technically, in browsers that support it, you could set CSSPlugin.useSVGTransformAttr = false to tell GSAP to use CSS instead but it's not really something I'd generally recommend. We place a high priority on browser consistency and when it comes to SVG, CSS transforms aren't entirely reliable in my experience. 

[manny2003]

@GreenSock

I had no doubt that you would have answered impeccably!

Everything you said make 100% sense to me and I really think you made the right choice in order to keep the best compatibility in all the situations.

I thought it was interesting to ask anyway about your point of view, just to be sure that using the .set() function in these cases was in fact the proper way to deal with transform attribute and CSS priorities.

 

I really appreciate that you have also kept the option to set CSSPlugin.useSVGTransformAttr = false if really needed! A great value in terms of freedom.

 

Thank you very much for the clarification and again congratulation for your work, keep up with the great job, GSAP is for sure one of the best bricks that makes websites all over the world as we know and appreciate them.

[GreenSock]

Thanks so much for the kind words, @manny2003! Happy tweening!