The Language of Shapes: Understanding the SVG Path

♪ Hi everyone, my name is Monica Wojcichowska, and I'm coming to you straight from Warsaw, Poland, where I'm excited to be talking to you a little bit about the SVGPAP. But before we get started, a little bit about myself. I was born and raised in New Jersey, but returned to my roots, and I'm currently living in Poland and eating all of the pierogi I can. If you ask LinkedIn, I'm officially a front-end developer and data visualization engineer, but if you ask my friends, they'll likely tell you that I'm a world traveler and lover of all things nature and sport.

But before I became who, what and where I am today, there were a few other things along the way, such as switching majors in college, switching careers from marketing to programming, switching countries I already mentioned, and of course, all the new things along the way, new passions, new people, new adventures, and the adventure continues. And the reason I'm telling you all of this in a bit more detail than a single slide introduction is to show by example that our paths are rarely straight. They bend, they twist, they turn, and the path rarely looks like this. It looks more like this, actually. And even when it does look like this, there's often some sort of roadblock that makes it inaccessible. But that's the super abstract path of life. And as much as I'd love to talk about that, today we'll focus on a bit less abstract of a path, the SVG path instead.

So what is the SVG? Well SVG, as a refresher for most of you probably, stands for Scalable Vector Graphic, and it uses shapes, numbers and coordinates instead of pixel grid for rendering, which makes it resolution independent and infinitely scalable. So if you want a little graphic, there might not be a huge difference, but when you start increasing the size, the difference between raster, which is the JPEG, PNG, GIF formats, and Vector becomes immediately clear as you can see from these images. This along with interactivity and accessibility are huge pros when it comes to SVG versus raster. But what's key for today's presentation is that it's not just an image format. It's actually a language for describing these 2D graphics. So I like to say that SVG is to graphics what HTML is to text. It's a way to display fill in the blank in a given structure. So where HTML has elements like divs, headers, lists, and paragraph elements, SVG has elements like the group container, circles, rectangle, lines, and even for an object. And of course, the SVG path element, which is the star of today's show. And why exactly is it the star? Well, because all basic shapes can be created with a path element. So the other elements that we mentioned, such as rectangle, such a circle, can be created using a path. So we have some basic shapes and less basic shapes. And then we have the things that you wouldn't even classify as shapes at all. Like this arch that's hopping across the screen, or this interactive drum set to the right here. We also have things such as clip paths, which allow us to basically create this mask and clip whatever is outside of that path. Like this birthday cake with different backgrounds. Or a text path, which allows us to lay out text along a path of our choice. So before we dig deeper, why understand the path? Well, huge potential. A path isn't just a visible line as I just mentioned, but it's a set of instructions that can be later used in a variety of different ways.

For pleasure, of course, because we often tend to enjoy things more as our understanding of them grows. And for practical purposes, such as introducing modifications or animations. So let's take a look at the path element along these lines.

Let's say a designer friend gives you a set of custom icons, and you want to introduce one little edit to one little icon. No big deal, right? Well, so you would think, but behind the scenes, something that looks like this looks more like this. It's a super long string of numbers, letters, and punctuation.

So let's learn to read this language. When we learn to read a book, we don't start with the book entirely, but we start with its building blocks. And the same goes for the path. So we have the path. Each path requires a path data attribute, which is signified by D, which is essentially a set of instructions, and it's chronological. We can read it from left to right, similar to reading a book. And the path data is made up of different commands. Each command is then represented by a set of letters and numbers, which tell us different things about that command.

So let's take a look at those building blocks, those letters and numbers. Well, SVG gives us 10 different commands, 10 different letters, and each command comes in two different variants, uppercase and lowercase. An uppercase letter specifies absolute coordinates on the page, and a lowercase letter specifies relative coordinates. So our first command, m, means move to. Basically pick up a pen and put it down in a certain location, so we just need to specify the x and y location. Line 2. This has to do with drawing straight lines from one point to another. So again, we just need to specify the x and y coordinates of our endpoint. Line 3. Next we have the horizontal line, here we just need to provide an x value because the y is assumed to be what it was. Same thing goes for v, the vertical line, just need to provide a y value. And then come the curves. So there's an infinite number of Bezier curves out there, but only two simple ones that are available in the path element, and that's the quadratic and the cubic. So c stands for the cubic Bezier curve. And it's used to create a smooth curve. So we need to define two points, two control points, and an end point.

And these two control points describe the slope of the curve at the starting point and the ending point. So basically the curve will start in the direction of the first control point and bend so that it arrives along the direction of the second control point.

The smooth Bézier, cubic Bézier curve is similar to the cubic curve except for that the control point of the first point is computed automatically as a reflection of the control point from the previous cubic or smooth cubic command. And if the smooth cubic command doesn't follow another S or C command, then it's assumed that both of the control points are the same. Both of the control points are the same.

Then we have the quadratic Bézier curve. So this is a slightly simpler curve command option that SVG provides us with. And in this case we only need to provide one control point which is the slope at the start and end point. T stands for smooth quadratic Bézier curve and it works similar to the smooth cubic cousin and then automatically calculates the control point as the reflection of the previous Q or T curve.

Now we move on to arcs. Arcs are sections of circles or ellipses. I'm not going to go too into detail here as the MDN documentation does a great job of that already. But from a high level it requires quite a few more arguments than our curves or lines did such as the X and Y radius, rotation, and some flags that define which of these four colored options we want for any given two points. And Z represents closed path which basically draws a line from our current position back to the initial point on the path.

But that's still a lot of letters to learn off the bat and what if we could simplify this? Well V, H, and Z are really just shortcuts for expressing a line that connects two points. So let's just take the non-shortcut notation and express them as a line instead. We can group the cubic curves together as well as S curves can be represented by C curves. Same thing goes for the quadratic curves and we can leave arcs to themselves. So that's a little bit of simplification. But also because quadratic curves which take three points to define them can all be written as cubic curves which take four points, we can also group all of these curves together as quadratics can be represented by cubics. And with an appropriate definition of control points where the first control point equals the second control point equals the midpoint of the start and end, all lines can also be written as cubic curves as well. So we're basically left with just three commands to understand the language of shapes. We really need to understand the meaning of M, C, and A. And that's a lot more manageable to wrap our heads around than a huge string of numbers and letters.

But there's one thing that still bugs me about this and that's the arc command and all of the variables necessary to define it. So, since we're already in the mood for simplification, let's just go all out. And it turns out that we're able to define an arc as a curve as well. Now, this isn't a one-to-one relationship where one arc equals one curve. But the arc can, with some complex mathematics, be approximated by a series of cubic curves. And this level of minimalism makes me a very happy camper.

And things are great! We know how to read something like this. We have a better idea of what this path data represents. But if we want to introduce an edit, we first need to find the exact spot within the path data where we want to introduce that edit. So I'd like to introduce to a tool I put together that does just this. But what fun would that be if I just said, go use this tool, and that's it.

Instead of just using it to do what we want, let's go behind the scenes and check out how it was made given our new understanding of the path language. So, in order to see where we are in the path, we first need to break it up into pieces. Luckily, we know that the pieces are commands. So, the pseudocode looks as follows. First, we parse our path data to JSON format, a format we know and love. And that's easier to work with than string in most cases. Then we can transform our path data to absolute format, just the uppercase version so we can get the start and end point of each of the curves and each of the segments to be clear. Then let's make the tool, render a single path per command. We'll scale them appropriately to make the tool usable for paths large and small. And we'll add some events such as on mouse over so that we can gain information as we hover over a particular segment. And an on change event, for example, if we edit the path data value so that our segments will update. And using a library called SVG path data, we're able to apply the transformations that we're looking for. So basically, taking a quick look into the code here, this function, get path commands as cubic curves is applying all of those transformations. So first, we're parsing to JSON format, we're making those values absolute, and then we're normalizing as such so that we just get the cubic curves that we're looking for. If we have everything in one format, in the C format, it'll just be easier for us to work with. Next, we need to get our single segment path data. So for all of the segments, we want to create a separate path. We just need to define the starting point where we want to pick up our pen and place it down, and then the curve. Then we get our segments. So we create a path, we apply the mouseover effect and an on-click effect for more information, we color them as needed, and we provide them with the data that we just defined above. If we take a look at the tool and how it works, we should have some interactivity. We should have some interactivity. So now I can see in the list to the left exactly where I am. I could also change this to parsed format, and it makes it even easier to work with. For example, if I want to apply an edit here.

And beautiful. I don't know if that's beautiful, but we apply the edit. So there we go. So, mission accomplished.

Well, awesome. We did it. We found the place on the path. But wouldn't our lives be a bit easier if this path manipulation was a two-way street? If we could go from data to visual but also from visual representation back to data? Well, in order to do so, we'd need some sort of click and drag functionality. When we click part of the visual, its data updates accordingly. And this is again where a simplification of commands into the cubic Bezier format really comes in handy.

So, our pseudocode again would look something along the lines of represent each command as the cubic Bezier version. Render the points defined by that command. So, the end point and the two control points. Add click and drag functionality to these points. In this case, we're going to be using React Dragable. On drag, we update the path data that's held in our local state. And once the drag ends, we have a callback that will update the path data that's held globally between the list and the visualization. Taking a look at the less pseudocode. Here, we're getting our points that we want to visualize. So, we're providing them with the path commands. And for each of the commands, creating a segment with drag handlers. And we're providing those drag handlers to react to draggables dragable element. So, if our points are visible, we handle that drag and on stop we have a callback that will update our data. So, let's take a look at the tool in action. And start from the beginning. Scale it as we want. We already explored our segments so we don't need to do that. But now we're interested in these points. So, let's say I want to make this look like it's even windier than the original. I drag these points any which way.

Let's curve this here. And I can also change the control points to bend as I please. And we were able to apply some edits. So I can copy all of this and then use it in some animation or as I please later on. So, voila. Edit text to graphic and to graphic to text. The two-way street we were looking for. And once you can tweak all of your paths, just imagine all of the animation potential.

So my time is short. And just a quick couple quick examples to show what you can do quick examples to show what can be done. The first shows our paperclip here and we're using a tween animation from Pop Motion combined with Flubber, which allows us to transition from one path to the next. So here, we just have three versions to tweak one original and we're switching from one to the other. In our next example, here we're using D3, which is my favorite, my go-to for animation from one state to the next, where we're basically combining it with a color animation. And things like this can really add a lot of a lot of flavor to your site or application. But the possibilities are really endless with your animation library of choice.

So to conclude on a philosophical note, I just wanted to say that the path is a beautiful thing, not just based on the product, but on the process of its creation, on the language it uses to get there. So structure doesn't limit or hinder our freedom, but it empowers us to realize it. Thank you very much. Links to the slides to the repo, where the tool is held, in addition to the tool itself, can be found here, as well as some of my information. If you have any questions or comments or especially top travel destinations for surf-loving digital nomads like myself, please feel free to reach out and check out the resources I've linked here as well.

Hello. Hi. Thanks again for joining us. We actually have some questions from your audience, so let's just get right into it, if that's all right with you.

Sounds great. Cool. So the first question is about performance. In terms of performance, is there anything important to think about? For example, is it better to render one long path or multiple little paths?

That's a good question, and I was actually thinking about that when making the tool I discussed as well as in general. So the documentation doesn't go into specifics when it comes to performance of the SVG path data property. But from personal experience, there is a slight, what single longer path is the slight winner? But again, this is just from personal benchmarking, and in my tool I use an approach where I render segments on top of the single long path, and the single long path renders faster. So that's something to keep in mind. But again, it's a minimal difference, and ideally, in an ideal world, the different segments or different parts of the long path would be rendered in parallel. So, again, slight difference, but single long path is the winner.

That's amazing. I would have totally guessed a bunch of short paths, but I guess if the difference isn't that big. Cool. Does the SVG path have any limitation as to what it can draw, or can you basically do anything with SVG?

That's a good question, too. So I talked a lot about how it's like the ultimate building block how you can draw everything with it. One limitation is when it comes to the arc command. You actually can't draw or it has difficulty drawing a complete circle or a complete ellipses. So that's because you're defining the start and end point as the same point, and there's an infinite number of circles that basically could be created from this one single point of start end. So a way around that is to sort of create the end point with a slight offset from the starting point, could be minimal, but again, some sort of difference so it knows where to start and where to end and then connect them with a separate path segment. Or to have circles for example. So again, you can draw anything with the SVG path, but maybe not with a single command.

Amazing. Circles are just real special shapes, aren't they? They are. Cool. We have a couple more questions. Let's see. If someone wants to learn about SVGs in general, are there any resources that you particularly like or that you would recommend following? Yeah, for sure.

So when it comes to the resources that I used, I included them in the presentation on the last slide. So I highly recommend the resources that are there. But a big shout out goes to the documentation. So the MDM documentation of the SVG path is clear. It's readable. It might take some more time to read through everything. But it answered most of my questions when it came to understanding. And when it comes to tools, there are different tools out there for cleaning SVGs. And so some other resources, when I was just creating examples for this presentation or playing around, I used SVGOMG, and I know that's pretty popular in the community as well for cleaning up SVGs. Yep. So those are two that I would recommend from the start.

Yeah, that's awesome. And what about any tools you'd recommend for developers when working with SVG? And like, when they're learning, do you recommend drawing stuff manually, like in an online IDE or using some sort of visual tool? OK. Well, I think that's just a matter of preference, whether you want to draw the paths yourselves. That could be helpful if you're trying to learn the commands in particular and what the different control points do and how they affect the shape of the curve. But what I would generally go for is take a pre-made icon, because icons are usually a single path or if not a single path then they're not a whole collection of paths, which a full SVG image might be. But icons are a good place to start. So they're SVGs as well, but they're not like the full graphic with a lot going on. So they're a good place, a good learning place.

Oh that's a good tip. I'm going to write that one down. Mike asks, hey Monica have you experimented with SVG morphing? If yes, which approaches do you prefer? IE, JS, CSS, etc. So yes, experimented is a good word for my experience with SVG morphing. So I wouldn't say I'm an expert in it. And yeah, there are multiple approaches for this. So you could technically use CSS for that but your path data needs to have the exact same structure. So shape 1 and shape 2 need to have the same length and CSS. And it's sort of there's limitations to morphing with just CSS. But it can be done. So an approach that I've used, and I have it on my personal site as well, is using Flubber.

So FlubberJS. It's a small library and it's simple to use. So you define the first shape or the first path and the second path and just interpolate between the two. And so there, the paths don't need to be the same length. They don't need to have the same amount of points or commands. And it produces the effect that I'm going for. So again, if you wanted some sort of specialized morphing function or whatnot, then you might have to experiment with writing your own, but Flubber basically accomplishes what I wanted to get out of it.

Awesome. The people want to know, I guess you've already talked a little bit about starting with icons, but whether you have any other sort of like tools that you use in your workflow and how do you sort of like start creating SVGs or generally source them?

Okay. So I, I generally just Google free, free icon. So I don't want to be caught up in any sort of like legal issues of using icons that I'm not allowed to use. But yeah, there's, there's some other tools out there that are similar to like the Adobe Illustrator. I don't have a license to Adobe Illustrator. So I I've used it before, but on the day to day, especially as a developer, not as a full-on designer, I just go to sites that sort of mimic it. So I don't have the names off the top of my head, but but they do exist.

So that's awesome. So that is our time for now. Remember that you can visit Monica in her speaker room after this. Monica, thank you so much for joining us and I hope you have fun in your Zoom room. Thank you.