What's this about?
Working on both side of the fence (design and dev) one learns to appreciate difference in approach and needs.
As designers we’re usually quite aware of resolution, file size when we working with raster image (JPG/PNG), but SVG seems to be more complicated. I suppose because it is more complicated, but also so much more powerful.
Now, what we’re talking about here I consider to be general best practices. There are few special cases where following workflow needs some adjustments. But this is a great starting base for most SVG usage for web.
Scalable Vector Graphics (SVG)
So not only its easily scalable, but also supports interactivity and animation. Not only the whole graphic, but the internal elements of graphics. This makes it so powerful.
SVG in HTML
It’s worth discussing different ways of adding SVG to a website or an app.
You can technically use adding it as a file – using <img> tag for example.
<img src="image.svg" alt="My SVG as a file">
But, and this is crucial. you will loose an option to control and modify the internal elements of SVG’s – which at times negates the very existence of SVG. The best practice is to have SVG implemented ‘as code’ inline (as opposed to ‘as file’).
Here’s an example:
<html> <body> <h1>My SVG</h1> <svg width="100" height="100"> <circle cx="50" cy="50" r="40" stroke="green" stroke-width="4" fill="yellow" /> </svg> </body> </html>
The more complicated the content of the graphic, the longer the SVG code. And very often I met resentment from developers – as it would make the code you see in editor very long. To be honest I was perplexed by this argument. I mean, even if you use <img> tag – the code generated will still be equally long. Loosing all the interactivity and animation of internal elements inside SVG only to save few lines (visually) in code editor makes no sense to me at all.
There are various methods to implement SVG as a code – and still keep it within one line. Depending on the framework architecture we’re working with: PHP, C#, Angular to name a few – all have elegant solutions to embed raw SVG code while keeping it in separate file.
Best tools to work with SVGs
What about sketch? Why not sketch?
I know, its quite easy and pleasant to work on vector illustration in Sketch. But even though being younger and much more modern package – its still way behind in terms of generating web-friendly SVG’s.
As as result, for me, Adobe Illustrator remains the tool for exporting SVG’s for web use. Additional benefit is that most developers are working on Windows machines. So in case they need to modify and re-generate SVG, they can use Illustrator.
Your favorite code editor Doesn’t really matter which one. Visual Studio Code, Atom, Sublime, or any of the rest of the bunch.
Creating sample SVG
I’ve created a simple graphic especially to illustrate issues that one can come across while working with SVG.
It has various elements, few shapes, elements with stroke and without, both simple and a bit more complicated objects, live text as well as text converted into outlines (shapes).
Now if we go ahead and just export this as SVG using default settings, we would get the following:
You might notice some issues with text, but before we got into this lets have a look at he code generated:
For those who are not web developers – let me tell you this is not the type of code you want to be working with. Actually this is one of the reasons for stereotypes and communication issues between designers and developers.
This code is just asking for trouble, especially on larger projects. SVG’s either icons, illustrations or what have you, usually don’t live in a vacuum and are not the lonely types. Typically a project can have anything between a dozen to hundreds upon hundreds of SVG’s
If all of them are generated like this – then how unique is for example class .cls-9?
The first issue here is that styling is not inline. While working on a website styling should not be done inline – for SVG’s – the oppposite is true. We want inline style in SVG’s. Why? To make sure that each SVG looks exactly like it should witout any global CSS messing around with it. Also, to make it easy for less capable browsers – not all browsers can handle such styling correctly.
Saving SVG the proper way
When generating SVG in Illustrator – Save as (instead of exporting)
Then make sure you select ‘Style Attributes’ (default setting is ‘Style elements’)
Once we’re on this dialog screen – its a good practice to have the following:
- ‘Decimal Places’ at 2
- Encoding at Unicode (UTF-8)
- Image location: Embed
- Responsive ticked
Lets have a look at the code now:
That already looks better, doesn’t it?
From 64 to 24 lines. But more importantly – the styling is moved to inline. No external CSS can mess around with that.
Ok, that’s a good start. But there’s still a few issues.
Live text vs outlined vector shapes
First of all – Live text ‘Text’ doesn’t look right. Looks like its not the right font. In fact – if you inspect the SVG you will notice that it’s indeed a different font being displayed.
In Illustrator, I have used chunky AbrilFatface-Regular, but its actually Times New Roman that is being displayed in the browser. Even the ‘More text’ text is not Arial anymore – New Times Roman again.
What the font? You might ask, well this would happen to fonts inside SVG’s – every time a user doesn’t have exactly the same particular font installed on their local machine, it’s being replaced with a default font.
Is the look of particular font important to you?
Can you guarantee that your user have the same exactly font installed on their local machine? Didn’t think so – the best solution is to convert text into shapes.
Changing text into shapes
In Illustrator select your text – go to ‘Type’ menu and select ‘Create Outlines’. Now it’s worth mentioning that this is not a non-destructive process. meaning you cannot go back to text from shape. For that reason its a very good practice to keep a version of your design with all text as text and saved in illustrator file format – so that you can quickly change text if necessary and generate new SVG (with new text converted to shapes).
This will also fix couple of less obvious issues – live text inside SVG’s can have random kerning, spacing. Changing into shapes removes all these issues.
After going back to Illustrator and changing txt to shapes, and also grouping and naming out layers, I’ve added one more important fix – removed any spacing between the artwork and SVG border:
Saving it now it’s important to have ‘Use Artboards’ ticked – that’s because I’ve modified the artboard to remove the spacing created by white rectangles.
Now my SVG in a browser looks exactly like the one in Illustrator
When we look at the code now – you’ll notice massive increase in code – that’s the cost of having everything in shapes instead of font.
This is a trade off I’m happy to do any day. Since SVG is not intended to hold a large amount of text. Therefore I don’t mind that having a few words is adding dozen of lines – tiny price for making sure that the writing is on brand and not switched to Times new roman with weird kerning…
One might also notice that now we have elements grouped with id’s added to what used to be layers or group of layers. This is massively helpful when one works with code, SVG modification, or animation – like GSAP.
Border or no border
Another thing to keep in mind – borders or rather Strokes.
We either want the strokes or not at all – depending on the nature of given SVG, how you plan to use it in the future. This is especially important for path/stroke animation.
If you want to animate ‘path drawing’ (or ‘stroke animation’ – naming differs) Then the graphic needs to be prepared especially for this task – using strokes with specific parameters.
For most other cases (when we do not animate paths) we don’t rly want strokes to be strokes. I want them to be actual shapes.
Why? Well, again – I’m thinking about potential usage of svg on the web. SVG’s are scalable – but some elements – like stroke width (or text for that matter) is not. The result – distorted look. Because while shapes are calculated in reference to the artboard/borders of SVG itself (think x and y coordinates). Unfortunately strokes are expressed in points – which are not relevant to the size of SVG itself. Therefore it will not be responsive, and will not be recalculated to stay in proportion to shapes.
Solution? Convert all borders to shapes – this way you can guarantee the final look on any browser on any device.
SVG in an awesome format, it allows for very impressive list of features (graphs, maps, charts), all while remaining responsive.
It’s one of the building blocks of any Design System, definitely part of any modern user interface either for websites or mobile apps.
It’s worth noting that browsers are getting better at dealing with SVG’s – so you might not notice some of the issues discussed there with modern browsers. But those less capable are less fortunate and still widely used. And since we aim to design and dev for all devices – it’s good to follow best practices.