Building a fully-accessible help tooltip

Today is one of those days that started out with a Google search for yet another accessibility question/concern. I’m working on a new project for my client Provata and part of that project is to build a sweet and seemingly simple help tooltip which explains to the reader/user what the Framingham calculator is.

The tooltip is triggered by a small help icon like the one shown in the top right corner of this screenshot:

As with every project, starting out by thinking about what HTML element to use to mark up a component was the first thing I did. But it turned out there is no HTML element to mark up a tooltip like this. And when we have no semantic elements to mark up our components, we are faced with the challenge to make sure that assistive technologies (ATs)—which are usually capable of understanding and conveying meaning via semantics—are able to understand what our elements really are and what they do.

ARIA attributes to the rescue?

Making elements more readable by ATs when HTML isn’t enough is possible using ARIA attributes. For example, you can get by creating a progress bar without actually using the not-too-well-supported HTML <progess> element. Making that bar look and behave like a bar is straightforward using some CSS, but if you’re using divs and spans to build it, you need to give ATs something more to make something of those non-semantic elements. This is where ARIA attributes like role="progressbar" and its companions, the helpful aria-valuenow, aria-valuemin and aria-valuemax (among others), come in handy. Sprinkling in some simple JavaScript, you upate the value inside aria-valuenow as the user progresses through whatever steps you provided them with and you’re generally good to go. You can read more about this on MDN if you’re curious or unfamilir with this.

Great.

We have an ARIA attribute value to help us indicate that a certain element is a tooltip: tooltip. Using role="tooltip" ATs know that this element is indeed a tooltip.

But tooltips are usually triggered by an action performed on another element.

Let’s first get back to the basics. According to Wikipedia:

The tooltip or infotip or a hint is a common graphical user interface element. It is used in conjunction with a cursor, usually a pointer. The user hovers the pointer over an item, without clicking it, and a tooltip may appear—a small “hover box” with information about the item being hovered over. Tooltips do not usually appear on mobile operating systems, because there is no cursor (though tooltips may be displayed when using a mouse).

I have a problem with the “Tooltips do not usually appear on mobile operating systems, because there is no cursor” part because mobile users have just as much right to get information on a page as non-mobile users. Whether you’re using a mouse or your finger, you should be able to understand what the Framingham score is, so this tooltip should be accessible in all contexts. And this is exactly where the fun starts.

I knew I couldn’t rely on hover alone (even though my client only requested hover) because, unless you have a touch screen with a fancy digital pen which allows for hover to be triggered, you won’t be able to see the hint inside the tooltip, and that is unacceptable.

I set out to make the tooltip show when the help icon is both hovered and clicked.

It is worth noting at this point that sometimes tooltips work on both touch and pointer screens without having to do any extra work, such as those that are shown as help labels on input fields, like this example by Heydon Pickering. In scenarios like this one, role="tooltip" in combination with aria-describedby are enough to indicate to ATs that this piece of text is indeed a tooltip which describes the content or functionality of the input field. Marking the tooltip up in this case is very easy because it’s already clear enough what it is. All that remains is for you to show/hide the text when the input field is focused, and this can be done using a couple of lines of CSS alone. The experience is great on mouse and touch screens, and everyone gets to experience it the same way.

However, things aren’t so straightforward when you have an example like the one in my project. And apparently I’m not the only one who’s been here and has been just as confused as to how to approach this.

Here are a few of the ideas that crossed my mind as I was thinking about the implementation of this:

Use a <button> to trigger the opening and closing of the tooltip. Tooltip would initially be hidden so that ATs won’t read it out loud as the user moves down the page. The tooltip interrupts the flow of the content in our project’s case and so should only be shown on demand.
“on demand” means when the user hovers/clicks/taps/focuses the trigger.
The tooltip would initially be hidden using display: none and only shown on demand.
Since semantics and “how machines would read this” is how I start all of my HTML code, I thought:
- if I use <button> I’ll have to use aria-controls to indicate what that button controls and that it will show/hide some element when it is clicked. All good.
Speaking of semantics, I could also use a link (<a>) that links to a specific section on the page, which in my case is the element containing the hint.
When using a link, the user will jump to the section on the page to which they’re being taken. I hate page jumps. I avoid them like the plague unless the decision to jump is intentional. (For example, a “Back to top” link on a very long page.)
In order to avoid the jump when using <a>, and in order to make the <button> open and close the tooltip, I need JavaScript.
For some holistic reason, I wanna avoid JavaScript and use it only when necessary. What if the user is a senior using some very old machine that has JS disabled?

Usually, when I’m torn between two solutions and when the JS-no-JS thoughts start floating in my mind, I look for second opinions. My first source of a second opinion is Google. I thought: “someone else must have built one of these before, and so must have somebody else too, so let’s see how they approached it and solved these issues”.

At this point I was still on the “I want to do this without JS if possible” boat, but believe it or not I love JS and was completely open to using it if the JS-based solution is better than all of the others.

Googling got me to land on a question that was exactly the same as mine. I found a lot of similar questions but all of them were more like the tooltip-on-input example. I found a very old thread started by Zoe Gillenwater who had the same question back in 2011 that I had today. I am aware that some technical details in there would/could be invalid today but the general principles are still valid. I highly recommend you read through that thread before continuing to read this article because everything else in here is based on some of the insights I got from that thread. Main points mentioned in the thread included:

Avoid using <button> and stick to <a> because links can be used to practically anything whereas buttons should be left for using in forms. I have to say I disagree here. If you know a very good reason to avoid using <button>, please let me know.
Using <a> you have to consider/remember:
- If you use <a> and have the hint be included inside of it:
  - The code looks like this:
```
      <a href="#" aria-describedby="#tip">
          
          <span id="tip"> Your hint text here </span>
      </a>
```
  - The text will be readable with the flow (which is not favorable in my case) because the content of the hint interrupts the flow of the information and data displayed in the main content.
  - Using CSS only, you can hide and show the text with display: none and display: block respectively when the link is hovered. This is good for sighted users using a mouse. However,…
  - If you hide the text using display: none inside the <a> and show it on focus, ATs won’t be able to read the shown text because the contents of the link are announced on initial focus only and won’t be re-announced when the text is displayed inside the link with display: block.
  - Testing this out I noticed that since the link doesn’t really link to anywhere, the user will jump to the top of the page when they tap the link on a touch screen. This is particularly horrible in our case because we have a long page and jumping up will only confuse the users. This can be solved using JavaScript to preventDefault on click.
  - (My opinion: I really dislike the fact that the link doesn’t really link anywhere. It’s a self-containing link, if that makes any sense, which negates the role of the link to begin with, in my opinion. So even though I tested it out of curiosity, I knew I didn’t want to use this.)
- If you use <a> and have it link to a separate piece of text (not a descendant of the link itself):
  - The code would be along the lines of: <a href="#tip"></a><div id="tip">  </div>
  - The link still causes a page jump unless using JavaScript.
  - On touch screens, tapping the link focuses it which in turn opens the tooltip, but the link image remains the same and there is no way to close the tooltip unless the user clicks anywhere outside it to remove its focus, which is not intuitive because there’s a lot of cognitive effort and guesswork and “how do I close this” guesswork and frustration involved, especially since the tooltip covers the content when open.

Every single no-JS solution came with a very bad downside that negatively affected the user experience. JavaScript is the way to make this work properly for every user in every context. It solves every one of those problems mentioned, except for the “this link doesn’t link anywhere” problem which can only be solved by, well, not using a link that links nowhere. :D (Some may disagree that a link not linking anywhere is not particularly wrong or invalid, but it’s not something I’d personally do.) I ended up choosing a solution that works, using JavaScript, and has a not-too-bad fallback as well. This pretty much covers the main thoughts and considerations I had throughout this. I will post the markup and functionality I ended up using in this project’s case study.

Conclusion(s)?

JavaScript is imperative to make fully-accessible interactive components. Sure, you can get away without using it in some cases, but a lot of accessibility requires JavaScript. Some ARIA roles and attributes are absolutely necessary to make components accessible, and many of those will simply not behave as they need to unless you make them work with JavaScript. Since my client is a health company, it is more likely that their users have one form of disability or the other than it is that they have JS disabled, so it’s safe to worry about not implementing JavaScript than about it not running.

If you’re interested in learning more about which attributes require what, I highly recommend checking out the ARIA Role Matrices from WhatSock. It provides and easy-to-scan and read overview.

Paul J Adam has also created a demo to show the different ways to show tooltips on hover. His examples still use JavaScript to make the components more accessible by toggling ARIA attributes as the tooltips open/close. This one is also definitely worth checking out.

Did I miss something? Let me know on in a tweet.

Four Tips for Getting More Work Done While Traveling

Staying productive during traveling can sometimes be a challenge. There are some things you can do to make the most out of your transit times and get more work done. Knomo—a UK based company that makes bags for digital nomads and techies like us, asked me to share some tips for staying productive while traveling. I shared four of the most important ones. I hope you find them useful! I will be sharing many more in another blog post too, so stay tuned!

This article is published @ Knomo London.

Mimic Relative Positioning Inside an SVG with Nested SVGs

Positioning elements inside an SVG image is very similar—if not identical—to positioning elements absolutely in HTML. Every element in SVG is positioned "absolutely" relative to the SVG viewport, and the position inside the viewport is governed by the current coordinate system in use. But this similarity in positioning elements should not conceal the fact that there is a fundamental difference between SVG elements and HTML elements: SVG elements do not have a box model like HTML elements do in CSS.

Before we move on, let’s quickly review what a box model is in CSS and how it affects positioning things.

Quick Review of The Box Model in CSS

Every HTML element has a box model in CSS that is composed of four boxes: the content box, the padding box, the border box, and the margin box.

The box model of an element in CSS—includes the content, padding, border, and margin areas. Image borrowed from the box-sizing entry in the Codrops CSS Reference.

Normally, when an element’s size is set, the width and height properties determine the width and height of the element’s content box. Any padding added to the element will increase the total computed width and/or height of the element—this is how the default box model works in regards to sizing the element. The box-sizing property allows you to control how the sizing of an element’s dimensions works. More specifically, using the box-sizing property, you can tell the browser to include the padding width and/or border width in the width of the element, without increasing that width. This is useful for many use cases, but mostly so for when you’re building grid systems in CSS, for example. You can learn all about this property and its values in this entry over on Codrops.

An element’s box model is also used to create a positioning context for the contents of the element, where applicable, or for the element itself.

When the value of an element’s position changes from the default static value, it either creates a positioning context for its descendants or for itself. Whenever the default position changes, a positioning context is needed to specify where and how an element is going to be positioned outside the default page’s content flow. (You can learn more about this subject here.)

If you want to remove an element from the page’s content flow, you can do that by positioning it absolutely. Positioning an element absolutely means it will be positioned relative to one of its ascendants, using that ascendant’s box as a positioning context.

Each positioning context, however, requires a coordinate system. The cooridnate system is established by the dimensions (width and height) of the element’s box model. Any descendant of the element will then be positioned inside and relative to the element using this coordinate system.

In SVG, however, there is only one coordinate system by default used to position elements inside the viewport: the current coordinate system in use, established by the SVG viewBox. And so when an element needs to be positioned inside an SVG, it is positioned relative to the entire SVG viewport.

Technically, there are two default coordinate systems in an SVG. But only one of those is relevant when dealing with positioning SVGs unless you explicitly change the values of both. If you're not familiar with SVG coordinate systems and how they're established and used, I highly recommend reading this article before continuing through this one. In this article, we'll be dealing with the ‘normal’ case where we only need to deal with one.

Individual elements don’t have a box model and therefore don’t have their own coordinate systems that can be used as positioning contexts for other elements. So, what if you do want to position an SVG element relative to another SVG element or group of elements?

The answer is: nested <svg>s.

Nesting SVGs

One of my favourite things about SVG is that it’s an image defined by markup. And that markup is what gives us a lot of power over the contents of that image and how they are displayed.

You can nest <svg>s. That is, you can put an <svg> inside another <svg>. And then you can put another <svg> inside that <svg>. And then you can put yet another svg inside that svg. And you can go on and on.

You can nest SVGs as deeply as you want. How many levels deep you want to go depends on what you want to do and whether or not you need to, of course. I’ve personally never needed to nest SVGs more than two levels deep.

<svg xmlns="http://www.w3.org/2000/svg">
    <!-- some SVG content -->
    <svg>
        <!-- some inner SVG content -->
    </svg>

    <svg>
        <!-- other inner SVG content -->
    </svg>
<svg>

Some notes about nested `<svg>s`

The inner <svg> element does not require specifying a namespace (xmlns) on it because it is assumed to be the same namespace as the outer <svg>’s namespace. Even the outer (root) <svg> does not require a namespace if it is embedded inline in an HTML5 document.
You can use a nested SVG to group elements together and then position them inside the parent SVG. Of course, you can group elements inside an SVG using the group tag <g>, but using an <svg> instead has a few advantages, such as being able to specify the group’s width and height, and positioning it using absolute values x and y instead of having to use transforms (for <g>). By specifying a width and height to the <svg>, you restrict the content inside it to the bounds of the viewport that is defined by the width, and height attributes. Any content that lies beyond these bounds will be clipped.
Percentage values specified for elements inside an inner <svg> will be calculated relative to that svg, not relative to the root svg. Percentage values specified on the inner <svg> itself will be calculated relative to the root svg.

So, Why Nest `<svg>s`?

One use case for nesting SVGs is creating interesting responsive effects where the contents of the SVG would hide or reveal other portions of content at different viewport sizes.

Such an example is the following SVG illustration of a small bird inside an egg:

Normally, if the SVG is responsive, resizing the screen would make the entire SVG smaller while maintaining the positions of the content inside of it and the spatial relationships between them:

Resizing the responsive SVG in the browser makes the SVG shrink in size, without affecting the position and spatial relationships of the content inside of it.

By nesting svg elements, we can create separate “layers” inside the root <svg> that we can then control so that the contents of these layers would change position inside the root svg as the viewport size changes. By doing that, we can show and hide different portions of content inside the SVG as desired.

By nesting svg elements, we can create separate “layers” inside the main <svg>

For example, we can separate the above illustration into 3 layers that would reveal the small bird on smaller sizes:

This effect is achieved by using different preserveAspectRatio values on each of the inner svgs. This ensures that the contents of each svg—i.e. the contents of each ‘layer’, ‘sticks’ to either edge of the root SVG, thus revealing the content in between.

I’ve written a detailed article about how to achieve this; so, if you’re interested, do check it out.

‘Relative’ Positioning in SVG Using a Nested `svg`

The fact that contents of an inner svg are positioned relative to that svg itself gets us one step closer to positioning elements relative to other elements as opposed to being relative to the root svg.

But how exactly does a nested svg enable us to position one element relative to another non-svg element?

Before we answer that question, we need to understand what an SVG element’s Bounding Box is.

What is a Bounding Box?

Not all SVG elements are created equal. The powerful thing about SVG is that its basic shapes allow us to create all kinds of non-rectangular shapes: from arbitrary paths, to open or closed polylines and polygons, to circles and ellipses.

Because of the nature of these elements and their lack of a CSS box model, the SVG specification compensates for the lack of a box model by introducing the concept of a bounding box:

The bounding box (or "bbox") of an element is the tightest fitting rectangle aligned with the axes of that element's user coordinate system that entirely encloses it and its descendants.

In simpler words, a bounding box is the smallest rectangle that you can draw around an element, that encloses the entire element—all its points and edges.

The light blue rectangle represents the smallest rectangle around the spiral shape, and thus is a visual representation of the shape’s bounding box. By selecting an element in the graphics editor, you can retrieve the properties of the element’s bounding box. In the above screenshot, these properties are available in Adobe Illstrator’s Transform panel.

Three kinds of bounding boxes can be computed for an element:

The object bounding box is the bounding box that contains only an element’s geometric shape.
The stroke bounding box is the bounding box that contains an element’s geometric shape and its stroke shape.
The decorated bounding box is the bounding box that contains an element’s geometric shape, its stroke shape and its markers.

An element’s bounding box is characterized by properties that can be retrieved using the getBBox() method—the SVG equivalent of getBoundingClientRect(): x, y, width and height.

var svgElement = document.getElementById('el');
bbox = svgElement.getBBox();

console.log( bbox.x ) ;
console.log( bbox.y ) ;
console.log( bbox.width ) ;  
console.log( bbox.height ) ;

Using the element’s bounding box, we can fake the presence of a coordinate system around that element, which we can then use to position other elements.

Using the element’s bounding box, we can fake the creation of a coordinate system around that element, which we can then use to position other elements.

More specifically, we will be creating and using an inner <svg> to establish a new cooridnate system around an element. The properties of the <svg> will be defined by the properties of the element’s bounding box: the x, y, width, and height properties.

Creating a new coordinate system around an SVG element

Suppose we have the following SVG image (courtesy of Vecteezy) with the bird and the nest:

Let’s have some fun. The bird in the above image is trying to get back to its nest. (My idea of fun is, admittedly, not than fun.)

Normally, we are able to position the bird above the nest by specifying its position inside the SVG using the entire SVG canvas’s coordinate system.

We can certainly do that.

But, ideally, we’d be able to position it by using percentage values that would be calculated relative to the nest’s “box”. We can mimic that by creating a coordinate system around the nest using our new <svg> element. The <svg> element has its own coordinate system established by its width and height. We will use that coordinate system to make up for the missing coordinate system on the nest.

Then, we move the bird (the actual bird content) into that <svg> tag. By being contained by the <svg>, the bird‘s position will be calculated relative to the coordinate system established on that <svg>.

But to create the relative connection between the bird and the nest elements, we need the positioning context of the bird—which is our <svg>—to resemble a coordinate system around the nest.

In order to do that, we will position the <svg> on top of the nest, visually. It’s important to note here that the inner SVG does not actually wrap the nest—the nest elements are not contained inside the <svg> tag. We’re only positioning the <svg> on top of the nest, visually, so that it seems as though the <svg> is the visual representation of the nest’s coordinate system.

In order to determine the exat position of the <svg> (its x and y position inside the root svg) and its dimensions, we will be using the nest’s bounding box properties.

The position of the <svg>—the x and y values—will be equal to the x and y values of the nest’s bounding box. That is, the bounding box of the group of elements forming the nest. (Groups can have bounding boxes, just like single elements can.) The inner svg will also have explicit height and width values which are equal to the height and width of the nest’s bounding box.

Here is what it looks like visually:

What the above image is missing is the fact that the bird is now contained inside of it. So this is what it really looks like:

The grey border is the border representing the bounding box, and also the new coordinate system around the nest established by the svg.

It’s important to note here that the bird is now positioned relative to the coordinate system of the inner <svg>. Notice how it is offset by some amount of pixels from both the top and left edges of the inner svg, just like it was positioned relative to the root svg. That is fine for now. We will need to get rid of that space to get a finer control over the position of the bird. But we’ll get to that shortly.

Another thing to note is that since the inner svg has an explicit height and width which are equal to the height and width of the nest’s bounding box, the bird’s feet get cut off at the bottom due to the way it is positioned. If you have other, more or different elements in your own projects, those might get cut off too. You definitely don’t want that. So to work around that, you need to explicitly set the overflow value to visible on the inner svg. This will ensure that the inner svg behaves only like a positioning context, not like a container that restricts its contents to a specific area visually.

Here is what the code looks like:

<svg id="birds" xmlns="http://www.w3.org/2000/svg" width="100%" viewBox="0 0 3945.8 2400">
    <title>Bird & Nest</title>
    <g id="nest">
      <path ...>
      <!-- ... -->
    </g>
    <!-- The ID I'm giving this SVG is just for demonstration purposes -->
    <svg x="698" y="1219" width="1055" height="641" viewBox="0 0 1055 641" style="overflow: visible;" id="coord-sys">
	    <g id="bird">
	      <path ...>
	      <!-- ... -->
	    </g>
    </svg>
</svg>

Just like with the root svg, the viewBox value of the inner SVG svg#coord-sys is determined by its dimensions.

Next up, we need to position the bird inside the new coordinate system. I won’t refer to the inner svg as “inner svg” anymore—I’ll be referring to it as svg#coord-sys.

Since we will be positioning the bird inside the svg#coord-sys, we need to be able to specify a position for the group of elements forming this bird. After all, the bird is not made up of one element only—it is a group of shapes. And so we need to position a group of elements, not just one element. The group of elements forming the bird is wrapped in a group (<g>) element.

But the problem is: the <g> element does not have x and y attributes. So we can’t simply move it to a specific position like so:

<g id="bird" x="50%" y="50%">

Usually, to move a group of elements around inside an SVG, we use SVG or CSS transform functions (translation transformation, most of the time). You can use transforms to move the group around, sure. But that would negate the whole idea we’re trying to achieve and would make the new coordinate system useless. After all, we could have used transforms to position the bird close to the nest inside the root svg without having to create a new coordinate system.

What we want is to mimic the way elements are positioned in CSS, relative to each other. So to say “move this group of elements to the position (x, y) inside this particular positioning context”.

Since <g> does not have x and y attributes, we’re going to substitute it with another <svg>.

<svg id="birds" xmlns="http://www.w3.org/2000/svg" width="100%" viewBox="0 0 3945.8 2400">
    <title>Bird & Nest</title>
    <!-- ... -->
    <svg x="698" y="1219" width="1055" height="641" viewBox="0 0 1055 641" style="overflow: visible;">
	    <svg id="bird">
	      <!-- ... -->
	    </svg>
    </svg>
</svg>

The svg wrapping the bird has an ID bird. This SVG, as opposed to its ancestor, will only serve as a container and, even though it does create a new coordinate system, we won’t be using that system. Using this svg, we can now move the bird around inside the new coordinate system established around (on top of) the nest.

At this point, it is best to get rid of the white offset space around the bird. The innermost svg#bird has the same dimensions and viewBox as its wrapping svg#coord-sys; which means that in order to move the bird around, we need to take this white space into account. So if we want to move the bird to position it at the top left corner of the system, we won’t be able to simply say set x and y to zero—we will need to use a negative offset in both directions to achieve it. That’s not practical. We would also need to take this offset into account wherever and however we want to position the bird later.

At this point, you need to be not only familiar but also comfortable with how the viewBox works. I’m going to assume you are. If you’re not, pause here and go read this article first.

We will change the value of the viewBox of svg#bird to crop the white space out. (So we are going to use its coordinate system, but only a little bit.)

By default, a nested svg will occupy 100% the width and height of its container, unless you tell it otherwise.

So svg#bird now has the exact same dimensions as that of the svg#coord-sys. It’s the one with the pink border in the following image:

We don’t need the dimensions to be different in this example so we will leave them as they are.

The image above also shows the amount of white space by which the bird is shifted inside that svg. So in order to “unshift” it, we will change the value of the viewBox of the svg#bird to crop that white space out.

<svg id="birds" xmlns="http://www.w3.org/2000/svg" width="100%" viewBox="0 0 3945.8 2400">
    <!-- ... -->
    <svg x="698" y="1219" width="1055" height="641" style="overflow: visible;">
	    <svg id="bird" viewBox="150 230 1055 641">
	      <path ...>
	      <!-- ... -->
	    </svg>
    </svg>
</svg>

That will shift the bird so that it is positioned at the top left of the coordinate system. I’m unfocusing svg#bird in the following image, so only the nest’s coordinate system is still shown, and the new position of the bird inside of it:

So now that the bird is positioned at the top left of its wrapper, we can move it around and get the expected result every time. For example, if we were to move the bird by 50% in both directions:

<svg id="bird" style="overflow: visible" viewBox="150 230 1055 641" x="50%" y="50%">

We would get the following result:

With this setup, we can now move the bird around inside the nest’s coordinate system just like we would move an HTML element inside another one in CSS. Both relative and absolute position values work here too.

Pretty nice, huh? This is possibly the closest we can (currently) get to relative positioning in SVG today.

Granted, to get here is not the simplest process, but once you’ve got a good grasp of how SVG coordinate systems and the viewBox work, it’s hopefully not so complicated.

Here is a live demo of the above bird and nest, with the position of the bird set so that it stands at the edge of its nest:

See the Pen [Article Demo] Relative Positioning in SVG by Sara Soueidan (@SaraSoueidan) on CodePen.

Final Words

The example used in this article is a very specific example and is, admittedly, not the most practical use case of all times. Your use case(s) are likely to be entirely different. You might be working with a very different SVG where you may not even need to do any viewBox cropping at all. If you create your SVG yourself, you can position your element (e.g. the bird in our case) at the top left of the SVG canvas, so that when you wrap it in another svg, it would also be positioned at the top left, and you wouldn’t have to do any cropping at all. I left this example slightly more complex just so we can cover more scenarios. (And because I was a little lazy to edit the SVG in Illustrator after having written half of this article. But I keep wanting to deny that.)

But the takeaway is how to mimic relative positioning using nested svgs. Whether you use one level, two levels, or more, the concepts are the same.

You might find this technique useful for positioning SVG UI elements relative to each other. Or maybe relative positioning in dynamically created SVGs. Your imagination is the limit.

I hope you found this article useful. Thank you for reading!

Making the Switch Away from Icon Fonts to SVG: Converting Font Icons to SVG

If you’re reading this article, then I can probably assume you’ve already decided to switch from using fonts for icons to an SVG icon system. Or maybe you're pondering the idea and want to get an overview of how that would be done and whether or not it's worth it. Either way, this post is here to help you with that.

If you’re not already convinced as to why SVG is a better icon system, then I highly recommend reading this article—a cagematch-style comparison between icon fonts and inline SVG for icon systems. Many companies and organizations including Github have already made the switch to SVG, and have written great articles explaining why they found SVG to be a better alternative. I’ve listed some articles at the end of this post for further reading.

Making the Switch

1. Grab your icon fonts files.

Font icons are font glyphs. They’re part of a web font and are thus defined in web font files and formats.

I don’t usually use icon fonts, so for the sake of demonstration, I headed to Fontello.com—an online icon font generator—to create an icon font that I can work with for this blog post. I picked a few icons and then generated an icon font and downloaded it.

Fontello generates a folder containing a demo page showing you how to display the icons on your own page and what class names to use.

The files generated by Fontello.

Among the generated files is the actual font used to define the icons. The font files are available inside a font folder.

The font file formats generated by Fontello.

These are the files you need to proceed. We’re going to be using these files to “extract” the icons and convert them to SVG.

2. Choose your tool.

To convert the icons to SVG, we can use one of the following tools:

fontello-svg: “a command-line tool to generate the SVG versions of a Fontello icon set, with a corresponding CSS file.”
font-blast: “You can use font-blast to extract icons from any icon font - Font Awesome, Foundation, anything from Fontello etc.”
Icomoon app: a web app for generating and creating icon sets in both SVG and icon font formats.

I’m sure there might be more tools to do this, but these are the ones I know about.

I’m going to be using Icomoon and font-blast in this article because they’re general tools that can be used with any font and are not restricted to just one. Both fontello-svg and font-blast are used pretty much the same way, and you can find extra information about fontello-svg in the Github repository’s Readme.

3. Convert the font icons to SVG icons.

3.1. Using Icomoon

To convert the font icons to SVG icons using Icomoon, we first need to upload them.

Your font icons will be available as an icon set in the app. The next steps are the same steps you would take if you were choosing from the set of already-available icons on the page:

Select the icons you want to download as SVG.
Click the Generate SVG & More button.

Like Fontello, Icomoon generates a folder containing the icons you generated, along with a demo page showing you how they can be used on your own pages.

The icons you’ve converted to SVG are available in the SVG folder.

There is one SVG file for every icon. The set is ready to be embedded in your page.

But before embedding the icons, you might want to sprite them. That is, create one SVG sprite that contains all of the icons, and then use that sprite to display each icon at a time, wherever needed on the page. Icomoon conveniently generates an SVG sprite (symbol-defs.svg) for you along with a polyfill (svgxuse.js) for older browsers that don’t support external sprite references.

3.2. Using font-blast

To convert the font icons to SVG icons using font-blast you need to first install font-blast using npm via your terminal.

$ npm install font-blast -g

The -g flag (short for global) ensures that you can run the script anywhere on your computer, regardless of the installation root.

As mentioned in the font-blast documentation, “You can generate icons from the command line by called the script with two parameters: the SVG file of the font, and the directory where inidivual icons should be placed”:

$ font-blast [svg-font-file] [destination-dir]

My command looked like this:

font-blast /Users/Sara/Downloads/fontello-08cdd41f/font/fontello.svg  /Users/Sara/Downloads/fontello-08cdd41f/svg-icons

Tip: You can drag your folder into the terminal, which will sort of drop the path to that folder into the terminal, so you don’t have to manually write it or grab it and then copy-paste it.

Running the above command, font-blast retrieves the icons from the font files and creates an SVG icon for each one, and saves the result to the folder you specify in the command line. My terminal then looks like this:

The result of running the font-blast command in the terminal, letting us know how many icons were found and converted to SVG.

The svg-icons folder I chose for the generated files looks like this:

The files generated by font-blast show the source font file used to extract the icons and include a folder containing the generated SVG icons.

As you have guessed, the SVG folder contains the generated SVG icons:

The font-blast-generated SVG icons.

The icons are then ready to be embedded on your page.

4. Sprite, Embed, Style, Animate, Have fun!

There are three main ways to create and use SVG sprites. I wrote an overview of these techniques here. We will explore each of these techniques in more detail in an upcoming article (or a series of articles), show the pros and cons of each one, and how to create and use the SVG sprites, so stay tuned.

You can subscribe to the RSS feed of my blog to stay up-to-date with new articles. An e-mail newsletter is in the works too!

SVG Style Inheritance and the ‘Flash Of Unstyled SVG’

There are too few things not to like about SVG, and I don’t mean the things that browsers cause by incomplete or lack of certain features or buggy implementations. Yet you might sometimes get some unpredictable results that might frustrate you when working with SVG, if you don’t know the details of how certain features should behave and what to expect from them, as per the specifications. SVG presentation attributes come with a bit of their own behavior which might sometimes surprise you.

I’ve written and spoken quite a bit about styling and animating SVGs with CSS, and have included a list of resources to dive into the details at the end of the article. I’ve also touched on the subject of style inheritance and the CSS Cascade in SVG in both speaking and writing. However, the topic is worth its own blog post.

I’ve been meaning to write this article for a while now but have been kept preoccupied. But what prompted me to finally write it today is this tweet I saw yesterday:

Issue: Oversized SVG icons when the page’s CSS fails to load https://t.co/FwkaBAzrAT
— Web Platform Daily (@openwebdaily) February 29, 2016

And I remembered that I have already mentioned the cause and solution to this issue in one of my talks as well as in the Smashing Book 5 chapter on SVG, but never in one of my articles, not even the article focused on making SVGs responsive with CSS. (See links at the bottom of the article.)

So, what’s the problem again?

When CSS is disabled or fails to load for any reason—such as when you’re on lo-fi, most SVG images, especially inline ones, will scale and take up the entire viewport width, thus making the unstyled page look even more ‘broken’ than it already does.

I’ve come across this scaling issue quite a few times in the past when I visited Codepen on my fairly slow connection (which sometimes gets more than just ‘fairly’ slow). The responsive Codepen logo would take up the entire viewport area, thus blocking the content underneath it and forcing you to scroll down to read whatever comes after it.

This—allow me to call it—Flash of Unstyled SVGs (FOUSVG) is caused by the lack of width and height attributes on the <svg> element.

But the SVGs are meant to be responsive…

So why would you want to set explicit dimensions on your <svg>when what you’re really trying to do is make the SVG fluid, right?

Right.

Ideally, we should make our SVGs responsive while also catering for any worst case scenarios where our styles are ignored or simply not applied for any reason.

By taking advantage of the SVG style inheritance tree, we can make our SVGs responsive while simultaneously planning for worst case scenarios, and providing a decent, less broken, fallback.

The How

In order to avoid the no-CSS scaling issue, all you need to do is not remove the width and height attributes from the SVG.

1. Keep the `width` and `height` attributes

This means that, if you’re creating the SVG yourself in, say, Adobe Illustrator, you should avoid checking the ‘Responsive’ option in the Export panel(s).

The ‘Responsive’ option in the new Illustrator SVG Export Options panel.

The ‘Responsive’ option in the older Illustrator SVG Export Options panel.

It’s very tempting to check that option, because you do want your SVGs to be responsive, after all, but you shouldn’t check it unless what you need is for the SVG to simply occupy the entire width on the screen—like when it’s supposed to be viewport-width, for example. (I’ve embedded an SVG in my current client project and I wanted it to occupy the full page width, so I safely removed the attributes.)

Unchecking the ‘Responsive’ option will ensure that Illustrator will export the SVG and preserve the dimensions it has.

2. Specify your desired `width` and `height` values in the CSS

You want your SVG to scale—be fluid—and fill out its container’s width?

No problem. Tell the browser you want that to happen by specifying the dimensions specified in the attributes above, using CSS properties:

svg {
	width: 100%;
	height: 100%;
}

or maybe something like

svg {
	width: 1em;
	height: 1em;
	/* maybe even... */
	color: currentColor;
}

which will restrict the dimensions of an SVG icon, for example, and scale it in proportion to the text it is inline with.

Specifying your desired width and height in the CSS will make sure the width and height attributes no longer restrict the dimensions of the SVG when the CSS is successfully loaded and applied.

If the CSS does fail to load, the browser will use the values provided in the attributes as fallback, thus preventing the excessive scaling of the SVG.

The Why: Why does the above technique work?

SVG presentation attributes are special style properties—a shorthand for setting a CSS property on an SVG node. For this reason, it only makes sense that SVG presentation attributes would contribute to the style cascade.

When I got started with SVG, I expected presentation attributes to be more specific than any other style declaration. It made sense to me that the “closer” a style is to a node, the more specific it is. For example, inline <style>s are more specific than external styles, an inline style attribute is more specific than <style> ‘islands’, so I thought it made sense for presentation attributes to be the most specific form of styles. But I was wrong.

Just like HTML presentational attributes, SVG attributes count as low-level author style sheets and are overridden by any other style definitions: external style sheets, document style sheets and inline styles.

SVG attributes count as low-level “author style sheets” and are overridden by any other style definitions: external style sheets, document style sheets and inline styles.

This makes it possible to provide a fallback for when the CSS styles are not available, so the SVGs still look good in their ‘worst’ case.

The order of styles in the cascade. Styles lower in the diagram override those above them. Presentation attribute styles are overridden by all other styles except for those specific to the user agent.

Tip: You can use presentation attributes to provide fallback for more than SVG scaling

If you have an SVG you’re styling and animating using CSS properties, you may start by ditching the presentation attributes altogether—we do have an option to do just that in Illustrator’s Export panel, by choosing CSS Properties over Presentation Attributes. That will lead to all attributes being exported as CSS properties, if they can be set as CSS properties.

You see, only a subset of all CSS properties may be set by SVG attributes, and vice versa. The SVG specification lists the SVG attributes that may be set as CSS properties. Some of these attributes are shared with CSS, such as opacity and transform, among others, while some are not, such as fill, stroke and stroke-width, among others.

In SVG 2, this list will include x, y, width, height, cx, cy and a few other presentation attributes that were not possible to set via CSS in SVG 1.1. The new list of attributes can be found in the SVG 2 specification.</small>

Some of the ‘new’ CSS properties for SVG are already implemented and available in Chrome today!

There is a benefit to keeping the presentation attributes inside the SVG as well, not just on the root element. These benefits are highlighted the most when you attempt to style the contents of <use>d elements in SVG.

When you re-use an element, the contents of that element are copied, as is, into wherever you place the <use> in the page. But you may want to re-use an element mutliple times and style each occurance differently. You can do that by leveraging CSS Custom Properties (a.k.a. CSS Variables).

When ‘theming’ multiple <use> elements with CSS custom properties, it is recommended to always keep the presentation attributes that provide the default styles for the reused SVG, so that the image is styled both when the CSS fails to load and/or when the SVG is viewed in browsers that don’t yet support custom properties. Without the presentation attributes, most styles—such as fill and stroke—will default to black, which is probably not what you want.

Weird SVG scaling gotchas to be aware of

Depending on how you embed your SVG, browsers will generally default to a 300px by 150px size, which is the default size for replaced elements in CSS. This is the default size you get for <iframe>s as well, for example.

If the dimensions of the SVG are not specified, or if they are explicitly set to auto, the browsers will default to the 300 by 150 pixels dimension. If either dimension is set to auto (instead of 100% as mentioned earlier), the browser will cancel out the value set in the presentation attributes and will default to one of the default height and width values.

Well, kind of..

Again, It Depends™.

You see, the browser behavior depends on how you embed your SVG. If you embed the SVG using <iframe>, you get the 300x150 as a default. If you embed the SVG inline in the document (using <svg>), most browsers will scale it to the width of its container and will scale the height proportionally to preserve the SVG’s aspect ratio, while Internet Explorer will scale the width but not the height, so you need to explicitly tell it to scale the height as well.

Fun fact: IE will scale the height of the SVG if you give it an explicit width value of 100%. Crazy, but true.

I’ve written more about the rendering of different SVG embed techniques in the ‘Making SVGs Responsive with CSS’ article linked at the bottom of the article, along with ways to ensure the SVG is ‘responsified’ across all browsers.

Amelia Bellamy-Royds has also gotten into more detail about the browser scaling techniques in her article ‘How to Scale SVG’ on CSS-Tricks.

Scaling Tip: Never drop the `viewBox`

Ever.

This is possibly the most important thing you need to be aware of when attempting to scale SVG: you need the SVG viewBox to properly scale SVG images.

you need the SVG viewBox to properly scale SVG images.

Do not remove it.

After reading this artilce, developer David Bushell shared his own experience highlighting the importance of the viewBox to make sure SVG images are rendered as expected. You can check his post out here.

Wrapping Up

Having explicit, non-percentage width and height values set on an SVG not only helps with fixing FOUSVG issues, but it also helps with other scaling problems, especially when the SVG is used as a background image in CSS. Internet Explorer sometimes refuses to scale the image properly if it doesn’t have its aspect ratio specified with the width and height attributes. I’ve had this happen even with non-background images recently as well. Quite honestly, I don’t know the details of why or when exactly this happens, but I do know that we can avoid it by having these attributes available anyway.

The viewBox is even more important than the width and height, so always make sure you keep it there. You can learn all there is to know about how the viewBox works in this article. It is a very powerful attribute that is definitely worth taking the time to master.

2015 In Review

Happy new year! 🌟
OK, I felt awkward starting a blog post that way—I confess. ☺️ But this is also an unusual post—not an article about CSS or SVG, and not a lengthy tutorial about web development. It is also the quickest post I ever wrote.

This is my first time writing a year in review kind of post. A lot of great stuff has happened in 2015 that I thought are worth documenting and have a look back at a few years from now. I’m grateful and thank God for every one of these things and everything else that has happened. And since a photo is worth a thousand words, I’ll start with a preview of the highlights in a few pictures, followed by sort of an alt text for each one, and then a little more:

Some of my favourite work-related highlights of 2015. From the top left:

Delivering the opening keynote at CSSDevConf 2015. Photo by Chris Casciano.
My 2015 speaker badges for the conferences: CSSConf AU, Smashing Conf LA, btconf Duesseldorf, Microsoft Edge Summit, Generate London, Velocity NY, CSSDevConf, View Source conf, ffconf.
Me accepting the Developer of the Year award at the net awards ceremony. Photo by and copyright of net magazine. (I think I look sleep deprived in that photo, but it was already two hours past my bed time, so, there’s that.)
Photo of the net award. (These things are very difficult to take proper photos of! ☝)
Photo of the O’Reilly Web Platform Award I received in April. (I took like ten photos till I finally got a decent one. 😅)
Photo of the first page of the “Mastering SVG for Responsive Web Design” chapter in the Smashing Book 5.
Me giving a workshop at Smashing conf LA. Photo by Marc Thiele.

In 2014, Manoela Ilic asked me to write a CSS Reference for Codrops. In February 2015, we finally released the 8–months worth of work & writing to the world.
This year, I also got published for the first time in a real book—the Smashing Book 5, which I contributed to with a very extensive article about using SVG in a RWD workflow.
Back in April, I won an O’Reilly Web Platform award. I had never heard of the award before I was informed about winning it, and so I had no clue that I was even nominated. That came as such a beautiful surprise!
Back in June, I was nominated and shortlisted for two net awards: Developer of the Year and Outstanding Contribution.

In September, I __won the *Developer of the Year* *net* award__. This was one of the most awesome things that have happened since I started doing what I do on the web, so thank you so much for each and every one of you who nominated me and voted for me. I am humbled and extremely proud! *You are awesome!* 💜

I published 23 articles. That’s an average of 2 articles per month, which I think is good. I like to take my time with the articles I write, as opposed to try to publish as much as possible during a specific period of time.
I spoke at 9 conferences worldwide—in the US, UK, EU and AU, including the first Microsoft Edge Summit, and gave my first workshop about SVG at Smashing Conf in LA.

(A lot of people ask me for videos of these talks sometimes. You can find a list of them—in chronological order— on my [speaking page](https://sarasoueidan.com/speaking).)

I gave two conference keynotes, one of which was the first day opening keynote—at CSSDevConf on board the Queen Mary (a boat!!) in California.

These seven points pretty much sum up the biggest highlights of the year, and the ones like to remember it with.

Of course, many things happened on a personal life level, but those don’t belong here, so I will spare you the list of them.

This one is on the weirder kind of highlights side, but definitely one of the things I remember 2015 with: I finally got a British visa! Those of you who have been following me in the last couple of years are already familiar with my visa stories. I apply for visas a lot, given the passport I hold (Lebanese) and then the places I speak in. I need to apply for a visa for most conferences I want to speak at, which sucks but is unfortunately necessary.

But one visa application that was particularly painful for me was the British visa, given how unfair the result was, simple because the person responsible for granting the visas was “not satisfied with my intentions in the UK”. 😒🙄 I decided to give it another shot last year for Generate London and ffconf, as well as to attend the net awards ceremony. After having showed evidence of my 10 previous speaking appearances at that time, the UK Visa & Immigration was finally convinced, and they granted me the visa. Woo.

Of course, 2015 wasn’t all rainbows and unicorns. I failed to do some of the things I was hoping to do, too.

Possibly the number one thing I regret to say that I didn’t do was to keep maintaining and updating the Codrops CSS Reference with new entries as I intended to.

With client development projects taking priority over all other work, and then the many speaking and writing commitments I had, it was very hard to find enough time to do this. Maintaining the reference requires way more time than I could possibly devote for it.

As such, I think it’s an appropriate time to officially announce that I am no longer the maintainer of the reference. (More news and updates about this will be shared on and by Codrops some time in the near future, so no elaboration is necessary at this point.) The reference is one those things I’m most proud of, and I know it will be well taken care of.

In 2015, I also managed to strain my wrist which is still not healed today. I can’t exercise like I used to, I don’t have enough strength in my left hand to do things that I would normally do with ease, and, well, it’s just frustrating. The pain comes and goes but it’s just not healed yet, which means I still have to see a doctor (again) and keep away from any form of physical activity that adds to the strain of it.

On the bright side: this means that I take longer breaks from work, which is something to add to the list of things I failed to do. I overworked and pushed myself to the limits, and reached the boundaries of a burnout mutliple times last year. This is one of those things I am currently working on and making sure it doesn’t happen again. Saying ‘No’ to stuff helps a lot, by the way. #protip

To keep this post short, I will skip the 2016 resolutions list. Partly because it’s not finalized yet, mainly because my goals aren’t really year-specific, so I’m not sure they count as “2016 resolutions”, and additionally because I’ve got a couple more announcements and updates coming that deserve their own blog posts. So, stay tuned!

I want my web site to be home for most (not all) of my articles and tutorials in the future, so make sure to subscribe to the RSS feed to stay updated with what comes next.

So, that was my look back at 2015. I’m really excited to see what 2016 will bring. I don’t expect it to be all good, because I’m a realistic person, but I do always keep a positive eye on the future.. or at least I try to.

What was your 2015 like? What have you accomplished and what are you most proud of? And what have you got planned for 2016?

Animated SVG vs GIF [CAGEMATCH]

SVG can do much more than display static images. Its animation capabilities are one of its most powerful features, giving it a distinctive advantage over all other image formats. They are one of many reasons that make SVG images better than raster images, including GIFs. But this, of course, only applies to images that are good candidates for SVG, such as:

Logos,
non-complex, vector-based illustrations,
user interface controls,
infographics,
and icons.

Of course, if you have an image that is better suited for the raster format—such as a photograph or a very complex vector illustration (that would normally have a very big size as an SVG), then you should use a raster image format instead. Not only should the image be a good candidate for SVG, but SVG should also be a good candidate for the image. If the image size is much less as a PNG, for example, then you should use PNG, and serve different versions/resolutions of that image using srcset, or <picture>, depending on what you’re working on and trying to achieve.

Not only should the image be a good candidate for SVG, but SVG should also be a good candidate for the image.

Generally speaking, the images listed above are usually perfect candidates for SVG. And if you’re going to animate any of those, creating your animations by animating the SVG code is the sensible way to go.

However, last week, a link popped up in my Twitter timeline that linked to a set of icons that are animated as GIFs.

The first thing that crossed my mind when I saw them was that they were perfect candidates for SVG and should be created as SVG images, not GIFs.

SVGs can indeed replace GIFs in many places, just like they can replace other raster image formats for candidates like those mentioned above. The ability to animate SVG images is what gives it this advantage and ability. And this applies to more than just animated icons.

So, here is why I think you should use SVG instead of GIFs whenever you can.

Image Quality

The first advantage to using SVG over GIFs—or any image format, for that matter—is, unsurprisingly, SVG’s number one feature: resolution-independence. An SVG image will look super crisp on any screen resolution, no matter how much you scale it up. Whereas GIFs—a raster image format—do not. Try zooming in a page that contains a GIF image and watch the GIF become pixelated and its contents blurred.

For example, the following GIF recording of an SVG animation looks fine at this small size:

A GIF recording of the SVG Motion Trails demo by Chris Gannon.

Zooming into the page a few times will cause the image to be pixelated and the edges and curves of the elements inside to become jagged, as you can see in the image below:

Whereas if you check the SVG demo out and zoom into the page, the SVG content will remain crisp and clear no matter how much you zoom in.

To provide crisp images for high-resolution displays when you’re using a bitmap image format like GIF, you need to use <picture> or srcset and switch the images up for different contexts.

Of course, the higher the image resolution, the bigger the file size will be. With GIFs, the file size will end up ridiculously large; but we’ll get to that in a minute. Also, using a high-resolution GIF and serving it at a smaller size for mobiles is bad for performance. Don’t do it.

When you create GIF-animated icons or images, their dimensions are fixed. Change the dimensions or zoom in and out of the page, and they’ll get pixelated. With SVG, size is free, and clarity is a constant. You can create a small SVG and have it scale up as much as needed without sacrificing image clarity.

Conclusion:

GIF	Animated SVG
GIF, just like other image formats, are not resolution-independent, and will therefore look pixelated when scaled up or viewed on higher resolutions.	SVG is scalable and resolution-independent, and will look crisp clear on any screen resolution.

Colors and Transparency

Perhaps the number one deal-breaker with GIFs is the way transparency is handled, especially when the image is displayed on a background other than a white background.

This is an issue that is most likely to emerge when using GIF icons (whether animated or not), since icons are usually created with transparent backgrounds.

For example, take the following circle with a stroke, created as both an SVG image (left) and a GIF with a transparent background (right). The problem is evident as soon as you look at the two images: the GIF circle has grey fringes around its stroke.

If you’re not reading this in the browser, the effect might not be visible to you because the figure styles might not be applied. Here is a screenshot showing the problem (on the right):

This happens because transparency in GIF images is binary. This means that each pixel is either on or off; a pixel is either transparent or fully opaque. This, in turn, means that the transition between the foreground color and the background color is not as smooth, and results in artefacts caused by inadequate sampling frequency, commonly known as aliasing.

When a line is not completely straight, it causes some pixels (around the edges) to be partially transparent and partially opaque, so the software needs to figure out what color to use for those pixels. The halo effect “is caused by all the pixels which would have been > 50% opaque being fully opaque and carrying the bg color against which they were rasterized” (Chris Lilley). So this effect is usually a result of pixel contamination from the color of the background against which the image was composited against upon creation/saving in a graphics editor.

Aliasing is usually countered with anti-aliasing, but that is not as simple when transparency is binary:

There is a severe interaction between anti-aliasing and binary transparency. Because the background colour of the image is mixed in with the foreground colours, simply replacing a single background colour with another is not enough to simulate transparency. There will be a whole host of shades which are mixtures of background and foreground colours [...]. The effect in this case is a white halo around objects, because the original image was anti-aliased to a white background colour.
— Chris Lilley (Source)

The solution to this problem is variable transparency, commonly known as the alpha channel, which allows for varying degrees of transparency and hence a smoother transition between the foreground and background color, which is not what is available in GIF; thus, the halo effect problem. Images with the halo effect usually look best when used with white backgrounds; any other high-contrast background color will make the artefact visible.

I’m not quite sure if there is a way to work around this issue, but I’ve not yet come across a GIF with a transparent background and curved edges that did not have this problem. I’ve even seen rectangular shapes suffer from it as well.

If you want to use your image/icon on a non-white background—say, on a dark footer background, this alone could be a deal-breaker. But there are other reasons SVG is better than GIFs too, that we’ll cover in the next sections.

Note: if you’re reading this article in a browser but still don’t see the fringes in the first image on a smaller screen, try zooming the page in to see the effect.

Why might you not be able to see the fringes on smaller sizes? The answer is: the browser smoothes the edges as a part of the image resize process. Does this mean that you can utilize this to get rid of the fringes and still use a GIF? Yes, you can. But to do that, you have to use a GIF that is much bigger than the size you want to render it at, and then resize it. This also means that you will be serving your users images that are much bigger than they need, therefore taking up more of their bandwidth on mobile, as well as hurting the overall page size and performance. Please don’t do that.

Conclusion:

GIF	Animated SVG
GIF images are capable of only binary transparency. This causes artefacts, known as the halo effect to show up whenever the image or icon is used on a non-white background. The higher the background color contrast with the image, the more visible the halo effect, which makes the icons practically unusable.	SVG images come with an alpha channel and do not suffer from any problems when they are used on different background colors.

Animation Techniques & Animation Performance

You can animate SVGs using CSS, javaScript or SMIL, and each of them gives you a different level of control that you can take advantage of to create all kinds of animations on SVG elements.

There are no “techniques” to animate GIF images. They are animated by showing a series of images—one for each frame—sequentially, in a fixed manner, at a fixed pace. You know, the way GIFs just work. Granted, you can get creative with your icons before you turn them into GIFs and then “record” the animation and convert it into a GIF, but how good will it look? And how much control over the animation timing will you get afterwards? None.

Unless you make sure you have at least 60 frames—that is, 60 images—per second to create your GIF, the animation will not look smooth. Whereas with SVG, achieving smooth animations is much easier and simpler by taking advantage of browser optimizations.

A GIF has a bigger file size than PNG or JPEGs, and the longer the animation duration, the bigger the size will be. Now, what if your animation plays for at least 5 ot 6 seconds? What if it plays for much longer?

You get the picture.

Let’s look at a more specific yet minimal example. Below are two images: an animated SVG on the left, and an animated GIF on the right. The rectangle in both images changes color over the course of six seconds.

The SVG image on the left and the GIF on the right.

There are a couple of things to note here:

The GIF animation looks smooth but if you look closely you will notice that the SVG rectangle is going through a wider range of colors as it transitions from the initial to the final color. The number of colors the GIF goes through is limited by its number of frames. In the above image, the GIF goes through 60 frames, i.e. 60 colors, whereas the SVG goes through the entire spectrum between the shade of pink used and the final green color.
For looping animations like this one, it is generally best to avoid the color jump shown in the above animation, and create the animation so that it reverses once it reaches the green color; that way, it will transition smoothly back to pink and then start the second round of animation from there too, avoiding that unsightly color jump.
With CSS, you can reverse the animation using the alternate animation direction value. But with GIF, you will need to work on your number of frames and probably end up doubling it to make this happen; this will, of course, also increase the size of the image as well.

The sizes of the two images shown above are:

GIF image size: 21.23KB
SVG image size: 0.355KB

This is no trivial difference. But we all know we can optimize our images. So let’s do that.

Optimizing the SVG using the SVGO Drag-and-Drop GUI brings the SVG’s file size down to 0.249KB.

To optimize the GIF, you can use one of the several GIF optimization tools online. I used ezgif.com to optimize the above image. (Other tools also exist; gifsicle is one of them.) The file size dropped down to 19.91KB.

There are many options you can choose from when optimizing GIF images. I optimized the above image so that the number of frames remains intact, using Lossy GIF compression, which can reduce animated GIF file size by 30%—50% at a cost of some dithering/noise.

You can also optimize it by removing every nth frame; that can reduce the file size even further, but at the cost of the animation not being smooth anymore. And in the case of an animation like the case at hand, removing frames will make the change in color be “jumpy” and noticeable.

Other optimization options are also available such as color reduction (which wouldn’t be suitable for our color-dependent animation here) and transparency reduction. You can learn more about these options on the ezgif.com optimization page.

To recap: If you want your GIF animation to be smooth, you’re going to need more frames per second, and that will consequently increase the file size by a lot. Whereas with SVG, you’re likely to maintain a much smaller file size. The above example is minimal, and I’m sure there are better ones out there, but I wanted the most minimal example to show the difference between the two formats.

Even if you were animating the above rectangle using JavaScript or even a JavaScript framework—since animations on SVG don’t work in IE, for example, the file size of that framework combined with that of the SVG is still likely to be smaller or at least equal to the size of the GIF image size. For example, using GreenSock’s TweenLite, the size of the SVG with the library combined would be less than 13KB (which is still less than the size of the GIF), since TweenLite is 12KB minified. If you do end up with a size equal to that of the GIF, the other benefits of SVG will tip the scale and you will be getting more out of it.

Some other JavaScript libraries exist that focus on certain animation tasks at a time, and come in impressivly small file sizes (<5KB), such as Segment which is used to animate SVG paths to create line drawing effects. Segment is 2.72KB minified. That’s not too shabby, is it?

There can be exceptions, so you should always test. But given the nature of GIFs and how they work, you will likely find that SVG is a better option in most cases.

Note: SVG Performance is not at its absolute best today, but this will hopefully change in the future. IE/MS Edge offer the best SVG rendering performance among all browsers today. Despite that, SVG animations will still look better than GIF animations, especially when you're tackling long animations, because the file size of the GIF—assuming it’s recorded at 60fps—will have a negative impact on the overall page performance. Libraries like GreenSock also offer impressive performance as well.

Conclusion:

GIF

Animated SVG

GIF images are generally larger than SVG images. The more complex and longer the animation, the more frames are required to create it and therefore the bigger the file size and the more the negative impact on performance.
Unless GIF animation plays at 60fps, the animation is going to be jagged and not smooth. Also, the more the number of frames per second, the bigger the file size, especially for longer animations.

Result: There will be a compromise that needs to be made. Either the GIF animation is smooth and the overall file and page size and performance is negatively affected, or the GIF animation will suffer with less frames. One form of performance is risked in both scenarios.

SVG images take advantage of the browser optimizations when animating elements. Even though browser performance on SVG elements is still not at its best, animation will still perform better without having to make page performance compromises.

SVG file size is still very reasonable, if not very small, compared to GIFs, even when certain animation libraries might be required to create cross-browser animations.

Maintaining & Modifying Animations

..is a pain if you are using GIFs. You will need to use a graphics editor such as Photoshop or Illustrator or After Effects, to name a few. And if you’re like me, then graphics editors are not where your skills shine, and you feel more at home when you make modifications in code, not in graphics editors.

Screenshot of the animation timeline as created in Photoshop. The lower part shows a fraction of the frames created for the animation. Fore more complex animations, more frames are required. Also notice the layers panel.

Thanks to my designer friend Stephanie Walter for the PS animation tips.

What happens if you want to change your animation timing? or if you want to change the timing functions for one or multiple elements inside your image? or if you want to change the direction in which an element moves? What if you want to change the entire effect and have the elements in your image do something completely different?

You will need to recreate the image or icon all over again. Any change requires you to jump into the graphics editor and work with frames and a frame-based UI. That would be like torture to developers, and a Mission Impossible for those of us who don’t know our way around those editors enough to make these changes.

With SVG, making any kind of change to the animation(s) is only a few lines of code away.

Conclusion (developer’s perspective):

GIF	Animated SVG
Maintaining and modifying GIF animations requires re-creating the image or resorting to a frame-based graphics editor’s UI to do so, which is a problem for design-challenged developers.	SVG animations can be changed and controlled right inside the SVG code—or anywhere the animations are defined, usually using a few lines of code.

File Size, Page Load Time & Performance

In the previous section, we focused on the performance of the animation itself. In this one, I want to shed some light on the page performance as a whole and how it is affected by the image format choice you make.

Fact: The bigger the file size, the more the negative impact on page load time and performance. With that in mind, let’s see how using SVG instead of GIFs can help improve the overall page load time by looking at a more practical, real-world example.

At my first SVG talk, 18 months ago, I mentioned how SVG can be used to replace animated GIFs and result in overall better page performance. In that talk, I provided a real-world example of a real-world web page that took advantage of what SVG has to offer and reaped the benefits: the Sprout homepage.

The Sprout homepage has two animated images that were initially created and displayed as GIFs. Two years ago, Mike Fortress wrote an article on the Oak blog, in which he explains how they recreated the animated GIFs, particularly the chart GIF (see image below) as an animated SVG image.

Note that the animation is created using SMIL so it will not be animating if you’re viewing it in Internet Explorer.

In his article, Mike shares some interesting insights on their new page performance as a result of making the switch to SVG:

This chart, and one other animation on Sprout, were initially GIFs. By using animated SVGs instead of GIFs we were able to reduce our page size from 1.6 mb to 389 kb, and reduce our page load time from 8.75 s to 412 ms. That’s a huge difference.
—Mike Fortress, “Animated SVGs: Custom Easing and Timing”

A huge difference indeed.

The Sprout chart is a perfect candidate for SVG. There is no reason to animate it by converting the animation into a GIF recording, when SVG can bring so much more benefits.

Jake Archibald realizes the power of SVG animations too, and uses them to create and animate interactive illustrations to complement his articles. His Offline Cookbook article is an excellent example (and an excellent article, by the way). Could he have used GIFs to do that? Of course. But given the number of images he used, the GIFs could have easily increased the overall page size to a couple or few megabytes, with each GIF being at least hundreds of kilobytes in size; whereas the entire web page currently weighs at 128KB only with all the SVG images embedded inline, because you can reuse elements in SVG, so any repetitive elements will not only cause the entire page to gzip much, much better, but for each page, the overall size of the SVGs becomes smaller.

Now that is impressive.

I will rest my case about page load and performance here. But it is still important to note that there can be exceptions. Again, in most cases, you’re likely going to find that SVG is better than a GIF, but you’ll always need to test anyway.

Conclusion:

GIF	Animated SVG
GIF images are generally bigger in size than SVG images are with animations added to them. This negatively affects the overall page size, load times and performance.	SVG images can be used and reused, as well as gzipped better, making their file sizes generally smaller than those of GIFs, thus improving page load times and performance.

Browser Support

Probably the only absolute advantage to GIFs over SVGs is browser support. GIFs work pretty much everywhere, while SVG support is less global. Even though we have many ways to provide fallback for non-supporting browsers—and current browser support should not be hindering anyone from using SVG, the fallback images, if provided as PNG or JPG, are going to be static, animation-less.

Of course, you can always provide a GIF as a fallback to SVG, but the previously-mentioned considerations and disadvantages should be kept in mind.

Conclusion:

GIF	Animated SVG
GIF images work pretty much everywhere.	SVG images have less global browser support, but they come with a lot of ways to provide fallback for non-supporting browsers.

Move something on a page, or anywhere, for that matter, and you’ve instantly added a distraction—something that is sure to grab a user’s attention as soon as it starts moving. This is simply how the human brain works. This is also one of the reasons ad banners are so focused on—and built with—a strong focus on animation. This is also why animated ad banners are extremely annoying. They are distracting, especially when you’re trying to perform a task on a page that requires your entire attention, such as reading an article.

Now imagine a page with a set of animated icons (or images) that just won’t stop animating no matter what you do. We’re no longer talking about one or two images on a homepage or within an article here; we’re talking about UI elements and controls, and smaller icons that are likely to be present in multiple places on a page, and on multiple pages. Unless your icon is supposed to be inifnitely animation—for example, if it is a spinner animating during a user-inactive waiting phase, then it is likely to introduce a problem, and become more of an annoyance, than a “nice thing”.

As a matter of fact, for some people it can become more of an annoyance, as continuous motion can literally make some people feel ill.

In her article “Designing Safer Web Animation For Motion Sensitivity”, designer and web animation consultant Val Head discusses the effects of overused animation on the web on people with visually-triggered vestibular disorders (emphasis mine):

It’s no secret that a lot of people consider scrolljacking and parallax effects annoying and overused. But what if motion does more than just annoy you? What if it also makes you ill?

That’s a reality that people with visually-triggered vestibular disorders have to deal with. As animated interfaces increasingly become the norm, more people have begun to notice that large-scale motion on screen can cause them dizziness, nausea, headaches, or worse. For some, the symptoms can last long after the animation is over. Yikes.

Now imagine if the animation does not end… Double Yikes.

Val’s article explains the problem in more detail, as she gathers feedback from two people who actually have these problems and share their experience with animation in different examples.

One of the solutions that can help avoid these problems is to provide the user with the ability to control the animation so that they can stop it when it gets disturbing.

With SVG, you can do that. You can fully control the animation and play it once or twice on page load—if you really need to have it play as soon as the user “enters” your page, and then fire it on hover for subsequent tweens, using nothing but a few lines of CSS or JavaScript. You do not need hundreds or thousands of lines of CSS or JavaScript to create an icon animation, unless your icon is a really complex scene with a lot of components that are animated inside of it. But I think that in that case, it does not count as an “icon” anymore, but more of a regular image.

You can go even as far as control playback, speed for each consequent tween, and much more, assuming, of course, you are using JavaScript to gain this level of control.

Or you can add a toggle to give the user the ability to stop an infinitely playing animation. You can’t do that with GIFs… unless you opt for replacing the GIF with a static image upon a certain toggle action.

Some might even argue that you could display a static version of the image—as a PNG for example, and then provide the GIF version on hover. But this comes with a few problems of its own:

If the images are inline, you’ll need to replace these images using JavaScript. That action does not require any JavaScript if you are using SVG.
If the images are foreground images (embedded in the HTML using <img>), and you need to replace these images, you will end up with double the amount of HTTP requests for every image. And if they are background images inlined in the style sheet (which is not recommended), the images (especially the GIFs) will add to the size of the style sheet and therefore to the overall render-blocking time of the page.
If/when you switch image sources on hover, there is a noticable flash between the first and the second image on slower connections. My connection is slow; sometimes 3G-slow, and I have yet to remember a time when an image was replaced with another one on hover, viewport resize, or whatever, and not have seen that flash. This situation gets even worse when the second image (GIF loaded on hover) is fairly big in size—there will be a flash, followed by a slow, janky animation of the GIF while it loads completely. That’s never attractive.

So, yes, you can switch image sources to control if or when the GIF animation plays, but you’re losing the finer control over the GIF and affecting the user’s experience with the UI.

You are also able to control how many times the animation plays in the GIF—which is pretty cool, but that means that the animation will play only n number of times. And then to re-fire the animation upon a user interaction, you will need to resort to the above technique with multiple images.

Multiple images to maintain, multiple HTTP requests, and an overall hacky, non-optimal solution to what could have been easily achieved with one SVG image.

Embed the one SVG image on the page.
Create the animation any way you want/need. (Or create the animation before you embed the image.)
Play, pause, control the animation; and give the user the ability to control it as well.

No extra HTTP requests for every image, no complicated animation timeline maintenance in graphics editors, and no accessibility concerns or woes that cannot be avoided with a few lines of code.

Conclusion:

GIF	Animated SVG
GIF images cannot be stopped by the user without requiring extra images and extra HTTP requests. Even then, the control is not full.	SVG animations can be fully customized so that they are enabled, disabled and controlled by the user without requiring any hacky approaches.

Content Accessibility

GIF	Animated SVG
GIF images are only as accessible as PNG and JPEG images are—using an appropriate `alt` attribue value to describe them. The content inside the image cannot be discerned or made directly accessible to screen readers beyond what the overall image description does.	SVG images are accessible as well as semantic. The content inside the image that is being animated can also be described and made accessible to screen readers using SVG’s built-in accessibility elements, and enhanced using ARIA roles and attributes as well. (You can read all about making SVGs accessible here.)

Interactivity

There’s not much to add here but the fact that you can interact with individual elements inside an SVG, during, before or after an animation, but that is not possible with a GIF. So, if you use a GIF, you will lose the ability to do anything beyond triggering or stopping the animation, and even those are not really done inside the SVG, as we’ve seen, but are achieved by swapping the GIF out with a static replacement. Even changing the colors of elements inside the GIF would require additional images to do so. That is yet another advantage to using SVG over GIFs.

Conclusion:

GIF	Animated SVG
Animations defined in GIF images cannot be interactive. You cannot interact with individual elements inside a GIF element, nor create links out of individual elements either.	SVG content is fully interactive. You can create hover and click interactions (and more) to which individual elements inside the SVG image can respond.

Responsive & Adaptive Animations

The ability to animate SVG directly from the code, as well as manipulate its many, many attributes, results in and adds yet another advantage over GIF-based animations: the ability to create responsive, adaptive and performant animations, without adding any extra HTTP requests, using a few lines of code, and with quite smaller file sizes.

Sarah Drasner wrote an article on Smashing Magazine showing different ways to animate SVG sprites. One of these ways is having multiple “scenes” inside an SVG, animating them with CSS, and then changing the SVG “view”—by changing the value of the viewBox attribute—to show one scene at a time, depending on the current viewport size and available screen estate.

If you wanted to create the same animation using GIF images, you would lose the animation control capabilities as well as require multiple images which are probably going to be bigger (in file size) than the one SVG image.

But if you don’t want to go with animating SVG code, you could always create an SVG sprite and animate it the way you would animate any other image format—using steps() and a few lines of CSS. Sarah also talks about this technique in her article. Animating SVG images does not need to be complicated, and is generally performant.

Conclusion:

GIF	Animated SVG
Given that content inside a GIF cannot be controlled with code, it is not possible to make the animations adapt or respond to viewport or context changes without resorting to seperate images.	Given that SVG content is directly animatable using code, the content as well as its animations can be modified so that they respond and/or adapt to different viewport sizes and contexts, without having to resort to any additional assets.

Final Words

GIFs have pretty good browser support, yes, but the advantages of SVGs outweigh theirs in almost every aspect. There might be exceptions, and in those cases do, by all means, use GIFs or any other image format that does a better job than SVG would. You might even use Video or HTML5 Canvas or whatever.

SVG can bring a lot of performance benefits to the table when compared to other image formats, especially GIFs.

Thus, given all of the above, I recommend that anywhere SVG could be used for animation, GIFs should be avoided. You’re free to ignore my recommendation, of course, but you’d be giving up on the many benefits that SVG animations offer.

Unless GIFs show a lot of advantages over SVGs that go beyond browser support for IE8 and below, then I believe SVGs should be the way to go.

A few resources to help you get started with SVG animations:

The State of SVG Animation
A Few Different Ways to Use SVG Sprites in Animation
Creating Cel Animations with SVG
GreenSock has a bunch of very useful articles on animating SVGs
Snap.svg, also known as “The jQuery of SVG”
SVG Animations Using CSS and Snap.SVG
Styling and Animating SVGs with CSS
Animated Line Drawing in SVG

I hope you found this article useful.

Thank you for reading.

Many thanks to Jake Archibald for reviewing and giving feedback to the article, and to Chris Lilley for his feedback re transparency in GIF images. It wouldn’t have been so comprehensive (read: ridiculously long) without their feedback. ^^

Tips for Creating and Exporting Better SVGs for the Web

Working with SVG in a RWD workflow usually involves a design phase and a development phase. The design phase is usually handled by designers who may or may not know how to code. And because of the nature of SVG as both an image format and a document format, every step taken in the graphics editor in the process of creating the SVG directly affects the resulting code and hence the work of the developer in charge of embedding, scripting or animating the SVG. In my day-to-day work, I am usually the developer whom designers hand the design assets over to, and SVG images are part of those assets.

Most of the assets I’ve been handed in my past projects needed a do-over and/or a second round of editing in the graphics editor before I could script them, because the resulting SVG code was not optimized enough for the kind of work—especially animation—that I was hired to do. The reason for that is that many of the designers I’ve worked with knew very little—if anything—about SVG code. They create vector graphics and UI assets all the time, but, for them, SVG is no more than an image format and they don’t know much about the code generated when their assets are exported as SVG documents.

There are some steps that designers can take or avoid—a set of “dos and don’ts”—that can help make the generated code cleaner. In this article, I want to share some of these. If you know any more, please do share them in the comments at the end of the article.

The tips we’re going to go over are applicable in Adobe Illustrator (Ai)—my graphics editor of choice—as well as other graphics editors. But since I personally use Ai, it is what I will be focusing on throughout this article.

We’re also going to go over the current SVG export options available in Ai and which ones to choose and why. But note that these options will change in the future, and this article will then be updated to reflect those changes.

That this article is based on my talk “SVG For Web Designers (and Developers)”—a talk I gave at CSSDevConf 2015 last month.

So, let’s start.

If you’re using Sketch to create SVGs, there are some things you can do to export cleaner code as well. Sean Kesterson has shared some tips in this article.

1. Create Simple Shapes Using Simple Shape Elements, Not `<path>`s.

There is a reason we have different basic shapes in SVG for creating, well, basic shapes. One could create practically any shape using a <path> element, right?

Simple shape elements (<line>, <circle>, <rect>, <ellipse>, <polygon> and <polyline>) are there for many reasons, and one of these reasons is that they are more readable and more maintainable and editable by hand than their <path> alternatives.

Basic shapes come with a set of attributes that allow you to control the shape features, such as position (x, y, cx, cy) and dimensions (width & height), while paths don’t come with these attributes.

For example, the following snippet shows the difference between a circle created and exported as a simple shape, versus one created and exported as a path:

<circle fill="#FFFFFF"
        stroke="#000"
        cx="28.1"
        cy="28.1"
        r="27.6"/>

<!-- versus -->

<path fill="#FFFFFF"
      stroke="#000"
      d="M55.7,28.1
         c0,15.2-12.4,27.6-27.6,27.6
         S0.5,43.3,0.5,28.1
	     S12.9,0.5,28.1,0.5
	     S55.7,12.9,55.7,28.1z"/>

If you want to animate your shape by, say, moving the position of the circle or making it bigger, you can do that by animating the position of the center via the x and y coordinates (cx & cy) and the radius of the circle (r). Whereas if you are working with a circle generated as a path, you will have to resort to CSS/SVG transformations (translation and scaling) to do that. And then suppose you want to animate that path and the animation requires you to apply further transformations to it? It can easily become a transformation mess.

Another advantage to using simple shapes is that, in the majority of cases, the code required to create a shape using simple shape elements is less than that required to create the same shape using a <path> element (see above snippet for a comparison), so using simple shapes will also result in a smaller file size, which is always better.

2. Convert Text to Outlines.. Or Don’t.

To convert text to outlines:

Select the text you want to convert.
Choose Type → Create Outlines

Pros:

Text converted to outlines will preserve the font face used, without having to use a web font to display it. This means you save a few extra HTTP requests and don’t risk displaying your text with a fallback font that generally doesn't look good enough to substitute the beautiful font of your choice.
Outlining the text and preserving the font face used is good for preserving a brand’s identity when the latter is defined by the font face used, for example: in a logo. I almost always turn logo text to outlines. Outlining is also good for preserving the font face of certain scripts when used for headlines.

Cons:

Text converted to outlines is not real text: it is a set of paths that form the outline (shape) of the text. Consequently, the text becomes unreal and inaccessible, not searchable and not selectable.
In the case of a script headline or even a logo where the text is outlined, using an alt text (if the logo is embedded as an image) or SVG’s accessibility elements (<title> & &>) is a good idea for providing alternative text for screen readers.

I highly recommend reading all about making SVGs accessible in these two articles by Léonie Watson:
- Tips for Creating Accessible SVG
- Using ARIA to Enhance SVG Accessibility
Converting text to outlines can significantly increase your SVG file size, depending on the complexity of the font face used. The image below shows the difference in the size (and readability) of an SVG with text converted to outlines (left) and text exported as SVG <text> (right).

Paths are not easily controlled and animated as <text> elements (including <tspan>s) are. The latter have a set of attributes that give you more control over your animations, while path data is limited in that sense.

3. Simplify Paths.

A path is defined by a set of points which in turn are defined by a couple of coordinates each.

The less the number of points, the less the path data (d attribute), and, consequently, the less the overall SVG file size. This is always a good step to take because a smaller file size is better for performance.

To simplify a path:

Select the path
Go to Object → Path → Simplify
Tweak the number of points. Make sure you have the Preview checked so can see how the path changes as you change the number of points. Tweak the number to get to the minimum number of points while preserving (or sacrificing) as much of the path’s visual appearance as you need.

There is a video tutorial created by Adobe to explain the process; so if you are more into videos, you can check it out here.

You can also simplify paths using the Warp Tool. I’m not a designer and I usually use Ai’s Simplify algorithm to simplify my paths, so, if you’re a seasoned designer, you probably already know much more about the Warp tool than I do. There is an article over at Smashing Magazine all about this tool, in case you want to check it out.

4. Avoid Merging Paths Unless You Don’t Need Control Over Individual Paths.

Many designers tend to combine or merge paths whenever possible. To merge paths:

Select the paths you want to merge.
Go to Window → Pathfinder
Click the Merge option among the list of options at the bottom of the panel (third icon from the left, shown in the screenshot below).

Combining paths may have its benefits, but avoid it when you or the developer needs to control and/or animate paths separately. Some animations are designed so that multiple elements are animated seperately, or sometimes you just want to style the paths using different fill colors. If you combine the paths, that will no longer be possible.

You need to make sure you know what the developer (or yourself, if you’ll be handling the development phase as well) needs and wants to do with the shapes you’re working on, and make the decision to merge or not to merge accordingly. This will save both of you a lot of time and friction.

5. Create Filters Using SVG Filters, Not Photoshop Effects.

If you use the filters in the Photoshop Effects section under the Effect option, Illustrator is going to export the effects you create as raster images. For example, if you create a drop shadow using the Blur Photoshop effect, the drop shadow generated will be a raster image embedded inside the SVG either inline or externally, using <image>. You definitely don’t want that when you work with SVG.

To generate your effects as SVG code, you need to use the SVG Filters available:

Go to Effect → SVG Filters
Choose and use one of the filters available in that panel.

6. Fit Artboard to Drawing.

Have you ever embedded an SVG on a page, gave it a specific height and width and then found that it was being displayed at a size smaller than what you specified?

In most cases, this is caused by an amount of white space inside the SVG viewport. The viewport is displayed at the size you are specifying in your style sheet, but the extra space inside of it—around the graphic—causes your image to “shrink”, because that white space is taking an amount of, well, space, inside the viewport.

To avoid this, you need to make sure your artboard is just big enough to fit the drawing inside of it, but not any bigger.

The artboard dimensions are the dimensions of the exported SVG viewport, and any white space in the artboard will be generated as white space inside the viewport.

To fit your artboard to your drawing:

Select the entire graphic. (I use cmd/ctrl + A.)
Go to Object → Artboards and choose the Fit to Artwork Bounds option.

7. Use Good Naming, Grouping and Layering Conventions.

I know this sounds like a no-brainer, but it needs to be emphasized for a few reasons:

The IDs and class names you use in the graphics editor are going to be translated to IDs and class names in the generated code. The more these names make sense and the clearer they label their respective elements, the less friction there will be when the developer works with the code.
Now, I'm not saying you have to think up the perfect names—I'm sure we all have different ways of naming things and naming can be one of the hardest tasks, but labelling groups appropriately goes a long way. For example, if you are drawing a car, then using an ID of wheel to name the layer or group wrapping the shapes making up the wheel would be appropriate. If you are grouping all wheels in one group, you might give it an ID wheels. Simple names to tell elements and groups apart go a long way and save a lot of time, especially if the developer will be editing and manipulating the code by hand.

Illustrator does not do the best job at naming things, so specifying names helps reduce the amount of junk it produces. Granted, there will be some extra editing required to get rid of the annoying underscores that Ai insists on generating, but using proper names helps make this process a bit easier.

As mentioned before, the next verison of Illustrator will show a big improvement in the way SVGs are generated, including generated IDs.
Use layers to group related elements. Layers are translated into groups in code, so name these well too. Create layers/groups to wrap related elements together, especially those that might be animated as a whole. A lot of time could be spent reordering and grouping elements by hand by the developer if this is not already done in the design phase. To save time, make sure you group appropriately. Talking to the developer in the design phase and designing how the animation will be executed together is a big time saver.
If the images you're creating are going to be used to create an SVG sprite, the names you use can and will be used by most automation tools to generate new files. So using clear and proper names will result in cleaner file names.

8. Choose The Best Suitable Export Options for the Web.

Starting with Illustrator CC 2015.2 released in November 2015, a new SVG Export workflow (File > Export > SVG) is available to export web-optimized SVG files for your web and screen design workflows. You can also choose to export individual objects versus the entire artboard. Refer to this article for details.

At the time of writing of this article, Illustrator comes with a bunch of export options that allow you to generate a generally better SVG code.

To export your SVG:

Choose File → Save As
Choose SVG from the dropdown menu
Click Save.

Once you click save, a dialog will show up that contains a set of options that you can customize, and that will affect the generated SVG code:

The options shown in the image above are the ones recommended for generating SVG for the web.

Of course, you can choose to Outline text if you don’t want to use a web font; Illustrator provides you with an option to do it upon export, as you can see, as well.

The Image Location option specifies whether any raster images will be embedded inline in your SVG or will be external with a link inside the SVG. This, again, depends on what you need. Inlining images inside the SVG can increase its file size dramatically. Last time a designer sent me an SVG with an image inlined in it, the file size was more than 1MB! After removing that image (which was caused by the Photoshop Effects used, that we mentioned earlier), the file size dropped to less than 100KB! So, choose wisely.

The CSS Properties option gives you the option to choose how you want the styles inside the SVG to be created: using presentation attributes, inline styles, or in a <style> tag. This is also a matter of preference and depends on how you intend to manipulate the SVG once you’ve embedded it. If you’re not the one who’s going to do that, make sure you consult with the developer to choose the option that suits their needs best.

The less the number of Decimal Places, the less the file size of the SVG. One decimal place should generally be enough, so I’d go with that.

Note that if you choose 3 or 4 decimal places, for example, and then use an optimization tool to optimize the SVG and bring that number down back to 1, the SVG might end up visually broken; so it is best to choose this option early on.

There is more to the options panel than what I have covered. Adobe’s Michaël Chaize has written an excellent article about the export panel that explains what each option does exactly. I highly recommend checking his article out:

Export SVG for the web with Illustrator CC

Now, at the time of writing of this article, Illustrator will still generate unnecessary code such as editor metadata, empty groups, among others, so you will need to optimize the SVG further after you’ve exported it, be it by hand, or using a standalone SVG optimization tool.

But before we jump into the Optimization section, I want to note that you may or may not want to check an extra option as you save the SVG: the “Use Artboards” option, in the Save panel:

This option is useful for when you are working with multiple SVG images (for example: icons) and you are using an artboard for every icon.

Exporting multiple artboards will generate multiple .svg files, one for each artboard (one for each icon).

If you are working with only one artboard, this option will be disabled by default.

Choosing to export one or multiple SVG files depends on how the SVG is going to be embedded.

For example, if you are going to create an SVG sprite for an SVG icon system, there are several ways you can create and use the sprite, and each one would require a different approach: one technique requires the icons to be separate at first, and another requires them to be part of one image.

I will be writing a separate post about spriting SVGs and the artboard options, but until then, you can get an overview of the different spriting techniques in the following article I wrote for 24Ways.org:

An Overview of SVG Sprite Creation Techniques

To Optimize or Not to Optimize...

It is usually recommended to optimize the SVG after exporting it from a graphics editor using a standalone optimization tool. The current most popular optimization tool is the NodeJS-based tool called SVGO. But it may not always be a good idea to optimize your SVG, especially if you intend to animate it.

If you intend to script and/or animate the SVG, you’re likely to set up a certain document structure—wrapper groups, ID names that you are not using/referencing inside the SVG but intend to use in your JavaScript, etc. This structure is going to change if you optimize your SVG using SVGO (or any other optimization tool).

Optimization tools usually remove any unused groupd and IDs, as well as apply many changes to the SVG to make sure it is optimized well.

I’ve once optimized an SVG after applying an animation to it using <animate>. The SVG was broken and so was the animation inside of it, because the entire structure was changed. So that is something to keep in mind before optimizing SVGs.

If you’ve manually edited and/or generated an SVG with a certain structure that you need, avoid optimizing using an optimization tool, and optimize by hand as much as possible. Some editor junk at the beginning and end of the SVG can be easily removed by hand. Other junk, such as metadata and classes generated by editors like Sketch—which has no SVG optmization options, can be harder to optimize by hand.

I generally never use Sketch to generate complex SVGs. I use Illustrator or Inkscape; the latter comes with a default export panel which gives you a lot of options to optimize your SVG before exporting it (see image below). Inkscape generates the cleanest SVG code at the time of writing of this article—that is, if you choose the Optimized SVG option, but the blurriness of the UI on a retina screen as well as its dependency on X11 on OS X make it a pain to use, so I am currently sticking with Illustrator.

If you do need/want to optimize your SVG, SVGO is the tool I would recommend.

SVGO comes with a bunch of plugins that you can fit into practically any kind of workflow. You can find more information about those tools in the following article I wrote a few months ago:

Useful SVGO[ptimization] Tools

9. Communicate. Communicate early.

Possibly the most important tip I can give is to communicate, and to do it early in the design process.

I’m now assuming that you—the designer creating the SVG—are not the same person responsible for developing the SVG (scripting, animating, embedding, etc.).

Almost every one of the above tips requires knowledge of the development phase and what the developer intends to do with the SVG—how they intend to embed, script, style and animate it. So, unless you’re the same person making decisions for both phases, and unless you want to waste a lot of time reiterating and editing the SVGs, you need to make sure you know what the developer needs to do with the SVG and what approach(es) they will be taking. If you’re working on a project that has a tight deadline, you probably can’t afford to waste a big amount of time making changes and revisions to image assets, when you can avoid that by communicating early.

Designers and developers can be each other’s best friends. The very nature of SVG requires both design and development phases to be open to one another, and this, in turn, requires the designer(s) and developer(s) to talk, before the design process begins, and throughout the process as well.

I hope this article helps save you some time in the future. I’m not a designer so I might have missed a few clever design tips. If you know any that would help generate better SVGs, please feel free to share them in the comments below.

Thank you for reading.

Developer of the Year 2015 net Award

Last Friday, I gave my first keynote in the UK at Generate Conf. That same day, the net awards were announced. On Saturday, I came back home with an award: the Developer of the Year award. This is a short thank you post to everyone involved.

A few months ago, many fellow designers and developers nominated me for two net awards: Outstanding Contribution and Developer of the Year.

Last Friday, the winners of the different categories were announced, and I’m thrilled to have won the Developer of the Year award.

I can’t even begin to explain how happy and humbled that makes me. To be recognized and appreciated by your fellow colleagues is a great privilege, and a badge I wear with pride.

I haven’t gotten a chance to say thanks to each and every one who congratulated me over Twitter after the award announcements—the feedback was so overwhelming (and fast!) that I just couldn’t keep up, so I thought I’d wait till I’m back home to write a thank you post instead.

So: thank you! Thank you to every one who nominated me and deemed me worthy of this title, and thank you to every one who voted and supported me. Two and a half years ago, when I started working in this field, I didn’t expect to be here today. I had different plans, most of which were unclear, and I never thought when I wrote my first blog post (on a really ugly blog design :P) that I’d end up shifting my overall path and doing all the writing and speaking that I am doing today. I am thankful to God and grateful for each and every step and opportunity I got along the way, and for all your wonderful support.

And now, since I’m really bad at coming up with proper ‘speeches’, I’ll keep it short and end with a huge Thank You one more time. You are awesome! ^_^

–S

CSS vs. SVG: The Final Round(up)

This is the last article in the series of article comparing common CSS techniques to their SVG counterparts. This article is a roundup of several CSS and SVG solutions, as opposed to being an article comparing one solution that can be achieved using either CSS and SVG. There are already a bunch of excellent articles out there that cover the details for each of these solutions, so we will get an overview of each solution and link to those articles for each section as we go. I highly recommend you check them all out.

This article is published @ Adobe Dreamweaver Team Blog.

CSS vs. SVG: Shapes and Arbitrarily-Shaped UI Components

This post is the third in the series of posts exploring techniques and examples that can be achieved using both CSS and SVG, and compares them both.In this article, we are going to go over techniques for creating arbitrarily-shaped UI components using CSS properties and SVG’s capabilities, and a mix of both! Specifically, we will be talking about how to create circular menus, as these are the perfect example of usable non-rectangular UI elements.

This article is published @ Adobe Dreamweaver Team Blog.

CSS vs SVG: Styling Checkboxes and Radio Buttons

This post is the second in the series of posts exploring techniques and examples that can be achieved using both CSS and SVG, and compares them both. In this article, we’re going to look into ways to style checkboxes and radio buttons using both CSS and SVG. You will learn how you can create animated checkboxes using SVG's line drawing capabilities.

This article is published @ Adobe Dreamweaver Team Blog.

Building A Circular Navigation with CSS Clip Paths

The CSS clip-path property is one of the most underused and yet most interesting properties in CSS. It can be used in conjunction with CSS Shapes to create interesting layouts, and can be taken to the extreme to create some incredibly impressive layouts and animations like the Species in Pieces project. While exploring the creation of arbitrarily-shaped UI components using CSS and SVG, it occurred to me that the clip-path property, when combined with SVG paths, can be used to create circular menus fairly easily, especially considering the (expected) browser behaviour when handling pointer events on clipped regions as per the specification. In this article, we'll explore this idea further and learn how it's done.

This article is published @ CSS-Tricks.

CSS vs. SVG: Graphical Text Effects

This post is the first in a series of posts exploring techniques and examples that can be achieved using both CSS and SVG, and compares them both. Since I am biased to SVG, this series is really intended to prove that SVG — because of its nature as both an image and a document format — is simply better than CSS when it comes to solving certain design problems on the web. But to keep an objective point of view, we will be weighing the pros and cons of each technique and find out where and when CSS or SVG can serve as a better tool to the design goals at hand. In this article, we’re going to look into the CSS background-clip and mask-image properties, as well as SVG pattern fills and masks.

This article is published @ Adobe Dreamweaver Team Blog.

Chapter 4, Smashing Book 5

The new Smashing Book is out! It’s packed with a lot of time-saving, practical techniques for crafting fast, maintainable and scalable responsive websites. I wrote a chapter in the book—Chapter 4: Mastering SVG For Responsive Web Design. Here is an overview of what that chapter covers, and why I think you should buy the book.

Photo credit: Mattia Compagnucci

I always get questions from my followers about a good place to start learning SVG. I write about SVG a lot, but I realize that it’s always better to have one place where you can jump start whatever you’re learning and then take it from there. I believe the SVG chapter in the book is a great place to do just that.

Chapter four of the Smashing Book 5 is 80 pages of SVG, covering everything you need to know to start implementing SVG in your responsive web designs today.

There is a chapter on SVG for RWD by Sara Soueidan that kind of made me feel stupid, not because of how it was written, that was great, but because it introduced me to so many new things about SVG. What the heck have I been learning all of these years? —Paul Scrivens, “Smashing Book #5, A Review”

So, What Can You Expect To Learn About?

Photo credit (and thanks to): Mattia Compagnucci

The answer to this question in my head is always a list of what is not covered in the chapter, because the topics covered include so much! Here is an overview of the contents:

What is SVG?: a brief overview of the image format and its history.
Vector vs. Raster: a comparison between vector and raster image formats such as JPEG, PNG, etc., characteristics of each, and what makes the SVG format stand out.
- Advantages of SVG: the many, many features that makes SVG a better image format for responsive web design, including but not exclusive to: scalability and resolution-independence, performance, accessibility, animation, and more.
- Vector vs Raster: Which is the Better Format?: a set of guideliness and things to consider when choosing the image format for your graphic, including why and when SVG might or might not be a good choice.
Quick Overview of SVG Syntax and Code including..
- Understanding the SVG Viewport and viewBox
Creating and Exporting SVGs in Vector Authoring Tools: tips, dos and don’ts for the right workflow when designing SVG images that ensure the resulting code is as optimal as possible. This section includes:
- Exporting SVG for the Web From Adobe Illustrator: overview of the export options and which ones to pick to make sure you end up with better code.
Optimizing SVGs Using Standalone Optimization Tools: there are a lot of tools, each can fit into a different workflow. We go over a list of some of the best tools.
Embedding SVGs: the different ways to embed SVGs on a page, and the pros and cons of each, tips on improving performance when choosing some of them.
Using SVGs as an Icon Font Replacement (or, How to Create SVG Sprites and Use Them as an Icon System): what the tite says. Sections covered in this master section include:
- SVGs vs Icon Fonts: SVGs are a far more superior icon system, and this section covers all the reasons why, as in intriduction to..
- Spriting SVGs: introduction to the concept, followed up:
  - SVG icon system with icons as background images: the how-to of creating an SVG sprite for icons used as background images on the page, including tools to simplify the process.
    - Covered is also a section about SVG data URIs, including any performance considerations.
  - SVG Icon System with Icons as Foreground Images: how-to and workflow automation tools.
    - Styling the icons and applying transitions to them: including styling the contents of <use>.
- Providing and Automating Fallback for HTML-Inline SVGs: some known and some lesser known techniques for:
  - SVG fallback as foreground images: how to provide fallback for SVG images that are embedded as foreground images. There are several options, all covered.
  - SVG fallback as background images: also a few options to choose from leveraging different CSS technqiues.
  - SVG Fallback Using SVG Conditional Processing (SVG Fallback as Background Image): SVG’s built-in fallback mechanism.
  - Other Fallback Techniques for different embedding techniques.
- Better SVG Spriting Using Native Fragment Identifiers: this is my personally-favourite SVG spriting tchnique and one of the lesser used ones, and the one closest to the way PNG image spriting works.
Making SVG’s Cross-Browser Responsive with CSS including:
- Making SVGs Fluid with CSS: everything including browser bugs and workarounds.
- Making SVGs Adaptive with CSS using CSS Media Queries to show and hide (or even animate) parts of the SVG depending on viewport size.
Making SVGs Accessible: the least you can do to provide even the most basic accessibility to your SVG images today.
Using SVGS to Optimize the Delivery of Other Image Formats: use cases that go beyond simply displaying or animating vector images. It includes:
- Using SVG Masks to Optimize Raster Graphics
- Using SVG As a Container for Serving Responsive Images a.k.a the Clown Car Technique.
Where To Go From Here: pointers to more ideas and resources to look into.

As you can see the chapter covers a lot. The topics it does not cover (otherwise it would have turned into a book) are: graphical effects (such as filters) and animation. I’m pretty sure there is even more about SVG to get into that the chapter does not cover, but hey, it’s only a chapter of a book!

Reading the new Smashing book, which is timely as I'm spritifying some SVGs, and it's easier than flying @SaraSoueidan over to do it for me. —Bruce Lawson

The Reviewers

The chapter was reviewed by Dmitry Baranovskiy (creator of the Raphael library and its modern Snap.svg alternative) and Jake Archibald (Google), both experienced SVG developers.

A Designer’s Complete Reference

The chapters of the book are complimentary to each other, so the entire book is a collection of topics that go extremely well together, giving you a set of diverse topics that are sure to come in handy for any responsive design project you work on.

While writing the SVG chapter, I mentioned the problems that non-vector images might bring up, and how the new <picture> element emerged as the almost-perfect solution for that problem. (SVG still has its benefits over these formats, of course, but raster images still have their place and importance where SVGs just can’t fill in.) And since my chapter was focused on SVG, I couldn’t get into the details of how to serve responsive raster images. Yoav Weiss’ chapter fills in that spot and covers everything you need to know about using responsive images. Not only that, but Yoav’s chapter also includes tips that you can apply to SVG images as well, making these two chapters the ultimate reference for images used in responsive design.

You can’t expect an SVG chapter to not mention SVG fonts, too. But then again, since that topic is outside the scope of what could be covered in the chapter, Bram Stein’s chapter on web font performance fills in that spot in his chapter that covers everything you need to know about web font formats, performance, fallback, and more.

The book was written by some of the brightest people in our industry, all experts in their fields, smarter than me, and known for their expertise in specific topics—all of which they covered in lengthy, very informative articles. You will find topics ranging from design workflows, patterns, to content choreography, images, advanced layout with Flexbox, responsive process, performance optimization, all the way to optimizing for offline experiences.

I hope you find the chapter on SVG useful, and I’m confident you will find the remaining chapters insightful as well. I promise you will not regret it.

So, what are you waiting for? Go grab your copy and feel free to tweet at us with any feedback or comments (or even pretty pictures)!

Buy the Book

Styling the Contents of SVG with CSS

An in-depth article on how to style the contents of the SVG <use> element and overcome some challenges it brings. We get into where the contents are cloned (the shadow DOM!), what limitations that brings up and how to work around them by taking advantage of the CSS cascade and using CSS Variables to get full control over the content while providing fallback for non-supporting browsers.

This article is published @ Codrops.

Art-Directing an SVG Embedded Using

Building a fully-accessible help tooltip

ARIA attributes to the rescue?

Triggering the opening/closing of the tooltip

Conclusion(s)?

Four Tips for Getting More Work Done While Traveling

Mimic Relative Positioning Inside an SVG with Nested SVGs

Quick Review of The Box Model in CSS

Nesting SVGs

Some notes about nested <svg>s

So, Why Nest <svg>s?

‘Relative’ Positioning in SVG Using a Nested svg

What is a Bounding Box?

Creating a new coordinate system around an SVG element

Final Words

Making the Switch Away from Icon Fonts to SVG: Converting Font Icons to SVG

Making the Switch

1. Grab your icon fonts files.

2. Choose your tool.

3. Convert the font icons to SVG icons.

3.1. Using Icomoon

3.2. Using font-blast

4. Sprite, Embed, Style, Animate, Have fun!

Recommended Reading:

SVG Style Inheritance and the ‘Flash Of Unstyled SVG’

So, what’s the problem again?

But the SVGs are meant to be responsive…

The How

1. Keep the width and height attributes

2. Specify your desired width and height values in the CSS

The Why: Why does the above technique work?

Tip: You can use presentation attributes to provide fallback for more than SVG scaling

Weird SVG scaling gotchas to be aware of

Scaling Tip: Never drop the viewBox

Wrapping Up

Further Reading

2015 In Review

Animated SVG vs GIF [CAGEMATCH]

Image Quality

Colors and Transparency

Animation Techniques & Animation Performance

Maintaining & Modifying Animations

File Size, Page Load Time & Performance

Browser Support

Accessibility Concerns (#a11y)

Content Accessibility

Interactivity

Responsive & Adaptive Animations

Final Words

Tips for Creating and Exporting Better SVGs for the Web

1. Create Simple Shapes Using Simple Shape Elements, Not <path>s.

2. Convert Text to Outlines.. Or Don’t.

3. Simplify Paths.

4. Avoid Merging Paths Unless You Don’t Need Control Over Individual Paths.

5. Create Filters Using SVG Filters, Not Photoshop Effects.

6. Fit Artboard to Drawing.

7. Use Good Naming, Grouping and Layering Conventions.

8. Choose The Best Suitable Export Options for the Web.

To Optimize or Not to Optimize...

9. Communicate. Communicate early.

Developer of the Year 2015 net Award

CSS vs. SVG: The Final Round(up)

CSS vs. SVG: Shapes and Arbitrarily-Shaped UI Components

CSS vs SVG: Styling Checkboxes and Radio Buttons

Building A Circular Navigation with CSS Clip Paths

CSS vs. SVG: Graphical Text Effects

Chapter 4, Smashing Book 5

So, What Can You Expect To Learn About?

The Reviewers

A Designer’s Complete Reference

Styling the Contents of SVG with CSS

The Results SVG Graphic

Choosing The Embedding Technique

Art Direction

Art-Directing The SVG <object>

Using JavaScript to Switch <object> Source

Inline or External JS? Sync or Async?

An <object> Extension?

Happy User, Happy Client, Happy Dev

Final Words

The State of SVG Animation

Some notes about nested `<svg>s`

So, Why Nest `<svg>s`?

‘Relative’ Positioning in SVG Using a Nested `svg`

1. Keep the `width` and `height` attributes

2. Specify your desired `width` and `height` values in the CSS

Scaling Tip: Never drop the `viewBox`

1. Create Simple Shapes Using Simple Shape Elements, Not `<path>`s.

Art-Directing The SVG `<object>`

Using JavaScript to Switch `<object>` Source

An `<object>` Extension?

Quick Overview Of the `viewBox` Parameters

Cropping the SVG Using `viewBox` a.k.a SVG Art Direction Using the `viewBox` Attribute

Using a CSS `viewBox` Property To Art-Direct SVGs

Things To Keep In Mind When Approaching SVG Art-Direction with `viewBox`

Extending the SVG Canvas using `viewBox`

Drawing A Menu Item Using SVG `<path>`

The Current `<img>`

The Bigger `<picture>`

Recommended Reading on `<picture>`

Blending Background Layers: The `background-blend-mode` Property

Blending An Element With Elements In Its Backdrop: The `mix-blend-mode` Property

Isolating Elements: The `isolation` Property

Nesting `<svg>>` Elements