Jump to content


SVG + GSAP workflow?

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

Hey there :)


I was simply wondering if there existed, somewhere, a practical workflow that one could follow when working with SVG – the aim being to streamline the process of creating SVG in Inkscape or Illustrator, then translating it into markup that GSAP understands.


I am not facing any particular issues at the moment, but I just finished working on an animation and it did cause some head-scratching.


For instance, if you save an Illustrator project as an SVG file and then look at the code, and paste some of the information on there in your JS files to feed them to GreenSock, the result often differs.

The reason for that is that, when you apply some transforms to your shapes in Illustrator, the software interprets some of it as actual transforms (which go into a transform matrix) and some of it as simply changing the shape's x and y coordinates. Then, when you enter the same info into your code, I think GreenSock just converts it all to a transform matrix, leading to varying (and sometimes wildly unexpected) results. Add to that traps like unaccounted-for changes in transform origins... and it can get pretty messy.


I'm not looking for a solution to the situation I described above, nor for explanations as to why it happened the way it did... like I said, I don't actually face any problem at the moment :)

I'd just like to know if there are best-practices and methods that are compiled somewhere that I could learn, to save some time for a future project. There's http://greensock.com/svg-tips, but that only provides examples of how GreenSock achieves various effects, not how to integrate all of those together and within a larger workflow.


As an example, I know that it's usually more efficient to use relative values in your GSAP code instead of relative ones (like x:"+=10"). I'm not sure I would be able to explain why, but I found that it led to less errors – not on GSAP's side, mind you, but on the translation from vector-editing software to JS code. The issue's on the human side more than anything :P



Link to comment
Share on other sites

Hi Acccent :),


I don't know if you'll find any one specific workflow that works the same for all designers/developers and all projects. 


You mentioned that you aren't facing any particular problem at the moment, but also said you had some head-scratching on your last project. If you had specific things that caused that head scratching, I'd bet you could get a lot of tips from everyone here to avoid those problems on the next project.


The only specific tip I'd offer that works well for me is always design your SVGs at the largest size you'll be needing. I find scaling down causes far fewer issues than scaling up.


I'd also recommend keeping an eye on Chris Gannon. He does some fantastic work and posts some helpful videos. Here's one about his alien/UFO animation that has some good information:



I'm sure others will jump in with their thoughts, tips and tricks.


Happy tweening.


  • Like 5
Link to comment
Share on other sites

That video is super interesting and exactly the kind of thing I'm looking for! One of the things he mentions which I think is important to know if you want to start animating SVGs using GreenSock, is that when applying an x transformation to an element it's always calculated relative to its position, not the whole document's.


So, you were wondering about what kind of specific situation I'm trying to avoid in the future, and I guess I can elaborate on that and the thing I alluded to in my first post...


Say you want to recreate something as simple as the cover of Jamie XX's Far Nearer.






Obviously the first thing you want to do is simply draw a rectangle in Illustrator, then rotate it by 45°. But when you do that, and have a look at the generate SVG code, you get a transform matrix, which admittedly you could give to GreenSock but then it's not very legible at all and pretty much removes your ability to tweak it out of Illustrator.


But even without rotating it, if for any reason you want that rectangle to move around... You – at least, I – create the SVG in Illustrator that corresponds to the starting state, then note that down into the html, then go back to Illustrator to move the rectangle to where I want it to go, and look at the new SVG code to use it with Greensock... except that doesn't work, because the values that Illustrator shows aren't usable by GreenSock.


Have a look at this codepen: 

See the Pen eJLWyy?editors=1010 by Acccent (@Acccent) on CodePen


In it you see that the rectangle has a starting position of x="20" y="20". Let's say I move it just a bit down in Illustrator so that its end coordinates are x="60" y="100", and then look at the SVG code: I get <rect id="movingrectangle" fill="#22FF99" x="30" y="90" width="60" height="20"/>. Now as you can see in the codepen, if I give those new values to GreenSock, it really doesn't move the rectangle 'just a bit down'. I couldn't find a way to go just where I wanted it to, except by using relative values.

edit: by the way: Chris Gannon says in the video that the relative positioning quirk only applies to paths and not other SVG elements, but it does happen with a rect as evidenced in the codepen.


I'm not saying Illustrator or GreenSock is at fault here, just that it would be useful to know a general method to move from one platform to another without this kind of issues cropping up! :)

Link to comment
Share on other sites

o.k. - I think I see what you're saying/asking. :)


It sounds like you're trying to animate an element to a specific set of coordinates relative to the parent SVG ? 


You're right - it's extremely important to know that all SVG paths, rectangles, circles etc... operate in their own little coordinate world. That means all moves are relative to their own starting position. You're not moving to any specific coordinates of the parent SVG, but rather a specified coordinate/distance from the element's starting point. So all three of these tweens will produce the same results and have nothing to do with the coordinates of the parent SVG:

.to(element, 1, {x:100})
.to(element, 1, {x:"+=100"})
.fromTo(element, 1, {x:0},{x:100})

Some may then think to return back the starting point, you'd move x:-100, but you actually move to x:0 (or x:"-=100" would work as well).


I made a super simple CodePen to show this:

See the Pen RrYgjo by PointC (@PointC) on CodePen


Relative positioning isn't really a quirk of SVGs, but rather an amazing feature because it all scales. For example - say you start with a 1,000 pixel wide SVG with a 100 x 100 rectangle child element in the left corner. To move that to the right side, you'd animate to x:900. Now, assume our parent SVG is scaled to 0.5. The whole thing is now 500px wide, but do we have to change our tween to x:450? Nope - not at all. Everything scales perfectly. You can scale my little demo down and all the boxes move perfectly at any size.


It also sounds like you go back and forth between AI and GreenSock so you can change your elements ending position by eye in Illustrator?


As you've found out, when you enter the ending coordinates into the tween, it's not going to work like you'd expect. If you do want to eyeball positioning in AI and then feed that info into GreenSock tweens, you have to find the starting and ending coordinates, do a little math to find the difference and then feed the difference into the the tween - not the ending coordinates.


So, if you've got an element at master SVG coordinates of {x:80 , y:200} and want to to move it to {x:300, y:300}, your tween would be {x:220, y:100}. Hopefully that makes sense.


o.k. - I may have rambled here, but hopefully it helps a little bit.


  • Like 5
Link to comment
Share on other sites

Well – I'm sorry if I wasn't clear enough, and I really appreciate the post, but as I showed on the codepen I knew all of that already.


I'm just saying: precisely! You need to know this! And it's not documented anywhere on official GreenSock pages, as far as I know, so you kinda need to either guess or just stumble into it once or twice to figure it out. And it can be a pain to understand what's going on if you don't know beforehand.


It's not really an issue of GreenSock 'allowing' scalable transforms, it's just a specifity. That's what I meant by 'quirk', and I hope the word didn't imply any negativity because that was not my intent: again, I don't think it's a problem with either GreenSock or Illustrator, it's just that they work in slightly different ways, both equally valid. I would probably say the same thing about InkScape or other vector software, but I happen to mostly use Illustrator.


To take your example, what I'm saying is if you applied Illustrator reasoning to GreenSock, and wanted to move the rectangle to the right side, you would use x: "900" regardless of its initial position. (ie. use values relative to the whole SVG document rather than the individual element.) You would also use this value even after scaling the parent element, since the 900 value is relative to the SVG canvas which is also scaled, if that makes sense. So really, it's not an issue of one approach allowing more things than the other, they're just slightly different.


And, anyway, that specific example is just that: an example! I was wondering if there was either a compiled list of these 'things to be aware of' somewhere, or a documented workflow, or procedure, or method... that avoids the pitfalls, or at least takes steps to correct the resulting problems and mistakes.


If there isn't, that's no big deal, I'll just continue learning through practise rather than theory ^_^

Link to comment
Share on other sites

Just to chime in.. SVG elements don't go by the same CSS box model HTML elements go by when it comes to transforms and its coordinate system. I don't think its a difference between Illustrator and the way GreenSock works. Since GreenSock is just a tool, and applies properties and values regardless.


In my opinion Acccent, i think most of the stuff that you feel should be documented in the GSAP docs regarding SVG would be a lot of info to document, that is already available in the SVG spec. Since i believe that type of info is useful regarding SVG. But that means GreenSock would have to document all the various types of behavior in the SVG, CSS, HTML, Canvas, and WEB-GL specs.


GSAP is just a tool, being able to animate any javascript numerical object and property. Even with CSS Transforms, a user would at least need to know or do some research to see how CSS transforms work. Some users might try to animate rotationY or the z (translateZ) but they would also need to know to set the CSS property perspective and transform-style: preserve-3d, to make it render in 3D and work. But that is not a flaw in GSAP's documentation. That is is just how CSS Transforms work.


The same could be said for a user who wants to animate an SVG using the z-axis or rotationY to animate in 3D space. But it wont work on SVG, since SVG does not support CSS 3D transforms. But that also would not be hit against the GSAP docs. Since that is just how SVG works.


I understand how you could think that the workspace in Illustrator compared to how GreenSock works in coordinate space. But in my opinion and experience i find that GSAP is working as expected. Applying properties regardless of how the local or global coordinates behave in the browser. GSAP is like a Swiss Army Knife, and is very versatile and adaptable depending on if its a DOM element, and SVG element, Canvas and/or Web-GL property.


I believe that the closest Adobe product that simulates SVG as far as local and global coordinates is Adobe Flash, which is also a vector program. But i understand when trying to tackle a problem, that usually its that little detail that can open your brains mind eye, creating that light bulb moment in solving the issue at hand. :idea:


Things can get even more confusing since browsers like Chrome will allow certain things that are not standard to the spec, like for example allowing some 3D transform on an SVG element even though it is not allowed in the spec. And then a couple of months later Chrome will remove that behavior to line itself with the spec, further confusing users. That is why as a rule of thumb i always test in Firefox first and a Google webkit and Apple webkit last. Since Firefox is always good about following the spec when it comes to web standards. And all webkit browsers act like the wild west!


When in doubt just check the spec! MDN (Mozilla developer Network) is a great site for keeping up with the spec and behavior of the various HTML, SVG, Canvas, and Web-GL properties and available values. MDN actually keep it updated unlike Google, Apple, and Microsoft which have very poor documentation regarding any spec. It will save you headaches, for the future to see what does what. :D


This link might clear things up on SVG user coordinate space versus SVG viewport coordinate space:




Just my two lousy cents with a side of pocket lint. Happy Tweening :)

  • Like 1
Link to comment
Share on other sites

I do not understand why the replies are so defensive of GreenSock. I am not criticising the platform! I'm very happy with it!

@Jonathan, you can't really expect someone to read the entire SVG spec to understand how to use GSAP... It's incredibly tedious to go through. You don't need to read the spec to understand how to use basic CSS transforms such as translations or rotations. I agree that if a user tries to apply a 3D rotation to an SVG, that's not a fault with GreenSock... But that's really not what we're talking about here.
And it is kinda illogical, in my opinion, to claim that just because GreenSock is a tool, there is no difference between it and Illustrator. Illustrator is a tool as well... and they treat some information differently... so how is that not a difference?
The article you linked is very interesting, but it actually confirms some of what I'm trying to point out... for instance, have a look at this extract, from part 2:


[For nested transformations,] the transformation applied to the child element will be an accumulation of the transformations applied on its ancestors and the transformation applied on it.

and the accompanying image:





Now check the codepen I made earlier ( 

See the Pen eJLWyy?editors=1010 by Acccent (@Acccent) on CodePen



As you can see, even though I'm chaining transforms, the translation is done parallel to the initial coordinate system, not the one that results from the rotation.


Maybe I am missing something here. I'm not even complaining about this behaviour: I find it easier to understand and more predictable.


I just thought it would be useful to have some kind of resource that mentions this.
I agree that it's not on GreenSock to provide the kind of document/article that I was asking about. I was simply wondering if someone who extensively knows and uses GSAP might have written that kind of information somewhere. I'm certainly not knowledgeable enough to do so, but maybe a professional web designer or graphic designer or UX designer somewhere had done it already. 

Link to comment
Share on other sites

Hi again :),


I don't think anyone meant to be defensive of GreenSock and for my part - I didn't mean to give you info that you already knew. I genuinely thought you were having trouble with the relative positioning. :)


Regarding your current question about rotating the coordinate system, I think I can give you a little bit of info. I completely understand why you'd think rotating a child element would rotate the coordinate system for itself, but it's actually quite good that it doesn't. If you rotated a child element 90 degrees and the coordinate system changed with it, x would now be acting like y and vice versa. Likewise, rotating 180 degrees would cause positive and negative to change. It could get confusing very quickly. 


In the article Jonathan sent you to, you'll notice she's rotating a parent group of the child to rotate the coordinate system.


I made a quick pen to show how you can change the coordinate systems easily by grouping elements. You'll notice in the first SVG, I rotate a group around the child rectangle and it then follows that new coordinate system as you'd expect.

See the Pen zrJyJo by PointC (@PointC) on CodePen


Again - I didn't mean to present any information that you already knew. Hopefully future readers that didn't know these things will still learn something from the post anyway.


All the best - happy tweening. :)

  • Like 3
Link to comment
Share on other sites

Yes, at least this very thread will hopefully show future users how to avoid the things that I might have had a hard time with in the past! ^_^


Regarding Sara Soueidan's article, I actually believe that she isn't transforming a group at all. (Well, she is transforming the 'parrot' group, but for the purposes of this discussion it can be considered a single element.) She mentions the following:



When you apply the transform attribute to an SVG element, that element gets a "copy" of the current user coordinate system in use.


So, to take your pen as an example, here's a fork that more closely illustrates the difference with the article:

See the Pen bExzdb by Acccent (@Acccent) on CodePen


In it, if it behaved like in the article, the square on the left would move diagonally. (However, like I said, I also think it's a good thing that GreenSock behaves the way it does.)


Thank you for your patient and cordial replies :)

Link to comment
Share on other sites

Hello again Accent, to be clear i didn't mean that you would need to know the whole SVG spec to know how to use GSAP. Just that knowing it will help you better understand how to apply GSAP.

So I'm very sorry if you took it that way! What i meant by saying that GSAP is just a tool, is that even with Illustrator when creating a composition. That having a good understanding of art principles like color theory, layout, balance, proportion, emphasis, movement, rhythm, form, symmetry, asymmetry, and harmony can be a big plus to help you use the program better.

Those art principles are not required to use Illustrator, but knowing those art principles and rules can be very helpful when creating complex comps, since Illustrator is an art drawing program at its core. Which is the same for SVG or any other web spec, knowing the rules can help you apply GSAP better.

That is all i was trying to say, sorry if it came off wrong, But again I understand what you mean and the point you were making! ;)


Happy Tweening! :)

  • Like 2
Link to comment
Share on other sites

Hi guys!


Great conversation here, I doubt I'll be able to address every point but...


Accent, to your first question:


I was simply wondering if there existed, somewhere, a practical workflow that one could follow when working with SVG – the aim being to streamline the process of creating SVG in Inkscape or Illustrator, then translating it into markup that GSAP understands.
I am not facing any particular issues at the moment, but I just finished working on an animation and it did cause some head-scratching.
I am not an artist or a master of the SVG spec but I can tell you that working with AI and exporting SVG to GSAP is certainly a challenge. Illustrator does totally different things to your SVG if you "save as an SVG" or "copy it and paste into an editor". In fact this discrepancy inspired my "how to not kill yourself exporting SVG from Illustrator" video: 
My general approach is "keep it dead simple and do everything you can to minimize revisions". Can't tell you how much time I spend re-applying classes / ids to SVG elements or cleaning up the SVG export in various ways. 
Would a guide on this be helpful? Absolutely. 
The problem is that this workflow is all very new and it is extremely difficult (and time consuming) to try to document these quirks when all it takes is a new version of illustrator to make it obsolete. (note Illustrator CC 2015 changed the SVG export options quite a bit, and it still isn't much better for the types of things web people need).
If you jump over to Flash, it handles SVG export completely differently – it uses the transform attribute for pretty much everything. Ugh.
However, despite these application quirks and the hassles of documenting such things, I agree a resource on how to handle what we might call "SVG Gotchas" is still a good idea. I'm sure there are plenty of general ones that don't apply to a specific app, but things like "coordinate space" as discussed above. I'll start a thread in this forum where people can list their workflow tips. I imagine that's what you intended this post to turn into  :-P but I'll make a new one so its more apparent and focused.
It seems at some points there were some misunderstandings / miscommunications about tone or intent. It seems like that is all worked out. Just want to say that I know from experience that Jonathan and PointC will bend over backwards to help folks with the best of intentions. I know they were just doing their best to give some valuable info. Its very tough to read tone in text. A simple exclamation can be read as excitement or anger. I know I'm plenty guilty of reading folks wrong or saying things where the intent gets muddled. 
Accent, I appreciate your effort in trying to move this conversation forward and not letting minor offenses get to you. I hope you feel welcome around here and we see more of you.
  • Like 3
Link to comment
Share on other sites

Regarding Sara Soueidan's article, I actually believe that she isn't transforming a group at all. (Well, she is transforming the 'parrot' group, but for the purposes of this discussion it can be considered a single element.)

Just a final thought here. You can group a single element. I made a quick fork of my pen to show you that diagonal movement you were expecting. Notice if I rotate the group with a single child element, the coordinate system rotates, but when I rotate the rectangle by itself, the coordinate system does not change.

See the Pen gPdEOP by PointC (@PointC) on CodePen


All the best - happy tweening. :) 

  • Like 1
Link to comment
Share on other sites

@Carl, I do feel welcome here and like to come by once in a while to see if I can help with anything – but usually, folks like @PointC and @Jonathan are already providing invaluable help. Which is why I never doubted that they had nothing but the best intentions! However, since new threads on here are often about users needing help with very specific issues with regards to how GreenSock works, concrete scenarios, I assume that my more 'general' question was kinda unexpected, haha. Of course, I'm the one to blame if I didn't manage to put my point across clearly enough :)


For my part, there is not an ounce of ill will, nor do I hold the shadow of a grudge against anyone haha. I am always impressed by how civil these forums are. You have my apologies if I disturbed the peace :P




@ @PointC: I do understand that you can group a single element to achieve the kind of manipulation shown in the article, however it's not obvious at first glance that it would be needed to create such a group. I made (yet another :P ) codepen to show that the exact same transform yields different results with CSS and GSAP: 

See the Pen MKqxqZ by Acccent (@Acccent) on CodePen

. The reason for the difference is because, with CSS, the element's coordinate system is transformed along with the element itself, while it isn't with GSAP.


This isn't a case of 'what's worse or better', it's just something that new users should be aware of, so it's probably worth mentioning in the new thread that Carl will create :)

  • Like 3
Link to comment
Share on other sites

i believe that is due to the order of operations in the transform function.


You will see that in the CSS animation keyframe rule.. that it first rotates and then translates the element. So right now it does this:

@keyframes squaretransform {
  from { transform: rotate(0) translateX(0); }
  to   { transform: rotate(45deg) translateX(150px); }

if you change the order of operation inside the transform function for the CSS to this, where translate is first, and then rotate:

@keyframes squaretransform {
  from { transform: translateX(0) rotate(0); }
  to   { transform: translateX(150px) rotate(45deg); }

You see that it follows a somewhat horizontal path, but not exactly the same:


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


Jack and Carl will be able to explain that behavior in GSAP, but it boils down to the order of operations within the CSS transform function. There is reason that it acts slightly different in GSAP. And has to do with making GSAP more consistent when rendered and animated cross browser. Since sometimes depending on the browser, you can get slightly and/or very radical results.


But like i said the Honorable Sensei's Jack and Carl can explain this behavior in regards to the order of operations in the CSS transform function and GSAP.


Please see this post reply from Jack:




and this:




Oh and Carl i love that AI Export Issues video, great stuff!



  • Like 2
Link to comment
Share on other sites

Great discussion, guys. Sorry I'm late to the party. 


Jonathan is exactly correct - the issue you described simply has to do with an order-of-operation thing. GSAP always uses the same consistent order so that you can depend on the results and you don't get the cross-contamination that often happens when you string transforms together in CSS. It has nothing to do with nesting or parent elements - it's just order-of-operation. If you rotate and then move, it's different than moving and then rotating. In my personal opinion, it's much more intuitive to always move then rotate so that the axis of movement doesn't shift with rotation.


While I firmly believe this is generally more intuitive for animators, it's not necessarily "better". One could argue that our consistency is a limitation ("what if I want to have the axis of movement shift with rotation?"). CSS technically gives you more flexibility in that sense. But flexibility can be a double-edged sword (causing more confusion). 


I also like the idea of having even better docs/resources to help people with SVG "quirks". We'll look for ways to do that better in the future. If anyone wants to tackle that sort of thing as a blog post or something, please feel free to get in contact with us and we very well may publish it on our site. Or even just a list of pointers.


Happy tweening!

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