Jump to content


SVG rotationX issue in safari and Firefox

Moderator Tag
Go to solution Solved by sirhclluk,

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 sirhclluk, and welcome to the GSAP forum!


Keep in mind that Firefox and Safari honor the SVG spec when it comes to rotation. the spec dictates that SVG 1.1 does not support 3d transforms, SVG 2.0 will support it but that is no where near coming out yet.


Chrome on the other hand will allow non standard behavior. So just because it works in Chrome doesnt mean it will work cross browser. Since Chrome will allow non standard CSS behavior so developers can test. But it is non standard and isn't allowed by the spec.


When you rotateX (rotationX) or roateY (rotationY) you are rotating that element with the z-axis since those elements will rotate intersecting on the z-axis.  But you should be able to use roate (rotation)


You have multiple tweens with rotation and rotationX in your example.

  • What part are you not seeing rotate in Firefox or Safari?
  • And or what code line?

They look the same to me in latest Chrome and Firefox on Windows 10.


Thanks for any additional info!

Link to comment
Share on other sites

Hi Jonathan

Here is a better example. 

See the Pen efc1f8d6779e1bb06365c6e43796075c by sirhclluk (@sirhclluk) on CodePen

So when his right arm bends is the big difference.

This is the first line with rotationX, 

.to(Bald_bicept_RT, .5, {rotation:45, rotationX:45, transformOrigin:"60% 5%", ease:Sine.easeOut}, "armR+=1.2")

Link to comment
Share on other sites

Thanks for the reduced codepen ;)


I see it rotate, so its not a rotate issue, but the alignment or origin of the elbow is off in Firefox.


This looks more of an issue with the transform-origin. have you looked in to the special property svgOrigin and smoothOrigin?




CSSPlugin svgOrigin:

  • svgOrigin [Only for SVG elements]
    Works exactly like transformOrigin but it uses the SVG's global coordinate space instead of the element's local coordinate space. This can be very useful if, for example, you want to make a bunch of SVG elements rotate around a common point. You can either define an svgOrigin or a transformOrigin, not both (for obvious reasons). So you can do TweenLite.to(svgElement, 1, {rotation:270, svgOrigin:"250 100"}) if you'd like to rotate svgElement as though its origin is at x:250, y:100 in the SVG canvas's global coordinates. Units are not required. It also records the value in a data-svg-origin attribute so that it can be parsed back in. svgOrigin doesn't accommodate percentage-based values.

    See the Pen 06716224865c2c536cee5b4222d771ee by GreenSock (@GreenSock) on CodePen


CSSPlugin smoothOrigin:

  • smoothOrigin (for SVG only)
    When changing the transformOrigin (or svgOrigin) of an SVG element, CSSPlugin will now automatically record/apply some offsets to ensure that the element doesn't "jump". You can disable this by setting CSSPlugin.defaultSmoothOrigin = false, or you can control it on a per-tween basis using smoothOrigin:true | false. Explanation: The way transforms and transform-origins work in the browser (and according to the official spec), changing the origin causes the element jump in a jarring way. For example, if you rotate 180 degrees when the transform-origin is in the element's top left corner, it ends up at a very different position than if you applied the same rotation around its bottom right corner. Since GSAP is focused on solving real-world problems for animators (most of whom prefer to smoothly alter the transformOrigin), the new smoothOrigin feature in GSAP solves this issue. This also means that if you create SVG artwork in an authoring program like Adobe Flash where it may not be easy/obvious to control where the element's origin is, things will "just work" when you define a transformOrigin via GSAP. Currently, this feature only applies to SVG elements, as that is where it is more commonly a pain-point, and we're eager to see how GSAP users employ the feature and share their feedback/suggestions before we consider adding it to "regular" DOM elements.

And check out this video on SVG smoothOrigin



Other helpful resources for SVG - SVG Tips:




See if that helps! :)

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.