[Scale broken on SVG text]

Awesome. Thanks for these updates, Jack. Looks like problems I was having with version 1.14.0 have all been fixed in 1.14.1. I'm really happy to finally tear down some of my onUpdate methods.

[Apply transforms with transform attr instead of inline style on SVG]

Fantastic work, Jack!

 

I'm testing everything out right now. I've already seen a couple of odd behaviors, so I set up a reduced test case here: 

See the Pen 7db9a3f2fcd0b945c566007971c68efc by kkrueger (@kkrueger) on CodePen

 

Chrome looks perfect.

Firefox is translating correctly, as expected, but the transformOrigin is being applied to the top left instead of 50% 50%.

IE11 doesn't appear to be translating at all, but is applying the rotation. transformOrigin is off here too, rendering at 0% 50% instead of the specified value.

 

Quick question: is there a performance gain in applying transforms with the inline style attribute versus using the transform attribute within SVGs?

[Apply transforms with transform attr instead of inline style on SVG]

Thanks Jamie,

 

The technique you mention is probably the most concise method of handling the issue. Though, it doesn't seem ideal from a performance standpoint. It sounds like it'll be a compromise one way or the other until, as you said, an in-built solution comes out.

[Apply transforms with transform attr instead of inline style on SVG]

Thanks so much. It's true, my workflow isn't too beautiful right now, and I'm the one on the project who was pushing to use GSAP.

 

I feel like there's a good solution just out of my reach. I mean, the exact values I need are already being generated in the case of a CSS transform, I just need that to move into another attribute.

[Apply transforms with transform attr instead of inline style on SVG]

Thanks for the reply, Jonathan.

 

Things aren't quite coming together yet. Looking at this little piece of code...

attr: { transform: "translate(0, -110)" }

...I was under the impression that a string like "translate(0, -110)" was untweenable and thus necessitated breaking them into their own properties, such as x and y. Am I wrong? Up until now, I had so strongly assumed that that wouldn't work that I didn't even try. I'll get a couple of test cases ready tomorrow, but haven't seen this working yet. Of course, I'd love this to work.

 

I've used some of the other methods you've mentioned above, such as using the attr plugin to tween the x and y properties of SVG components, and that's worked wonderfully. I'm at the point where I am now because x and y aren't options with <path> or <g>, both of which I need translation control over. And CSS transforms applied to SVG elements is limited to webkit, for viable results.

 

Thanks again

[Apply transforms with transform attr instead of inline style on SVG]

I've noticed that GSAP applies transform properties to SVG elements via the inline style attribute instead of the native SVG transform attribute: https://developer.mozilla.org/en-US/docs/Web/SVG/Attribute/transform. This tends to be a browser compatibility issue, especially with IE. I cross referenced Velocity JS, and it looks like there's some feature detection built in that deals with this issue.

 

Am I missing something? Or does GSAP have a method of accomplishing this easily? I should note that I already have some functional code, but it's a lot more verbose than I'd like it to be; onUpdate functions running after every tween.

 

To be sure I'm clear, I want:

 

transform="translate(40, 60)"

or

transform="matrix(1,2,3,4,5,6)"

instead of

style="transform: matrix(1, 0, 0, 1, -45, 75)"

 

(ignore number values)

 

 

Thanks for the help