SVG
Illustrator Settings | Sprites | Ani

SVG CREATION IN ILLUSTRATOR

Export art to SVG – EXTENDED BREAKDOWN

https://helpx.adobe.com/illustrator/how-to/export-svg.html

To save your artwork artwork as SVG, choose File > Export > SVG (svg).

Check Use Artboards if you’d like to export the contents of your artboards as individual SVG files. Click Export to
open the SVG Options dialog.

Note: If the Use Artboards checkbox is left unchecked, the SVG file’s viewport will be set by the combined bounds of
all the objects in the document.

Export individual components

SVG Export also allows the export of individual components, or entire sections of a design, rather than the entire
artboard.

To export a section or component of your design to SVG, select it, and then choose File > Export Selection >
SVG (svg).

Enter SVG Options

• Styling: “Presentation Attributes” means stuff like fill: red; rather than “Inline Styles”
  which means style=”fill: red;”. Presentation attributes are easier to override in CSS. Inline styles provide
  more style resilience. There is also an option to export styles in a <style> block within
  the SVG, which may be efficient on SVG with lots of similar elements.
• Font: “SVG” means to use elements (and friends), which is extremely efficient, provided the
  fonts you’ve used are available on the web site you intended to use it on. “Convert to Outlines” will turn
  the text into vector shapes on export, making sure it will look exactly right, but losing efficient,
  accessibility, searchability, and copy-ability.
• Images: “Link” means that if there happens to be raster graphics within the SVG, it will
  link out to them rather than embedding them within the SVG, versus “Embed”ding them.
• Object ID’s: Unique ensures that every ID is unique (good for the web), but you also have
  the option to make them very short (“Minimal”) or be based on layer names.
• Decimal: 2 is probably fine. You’d only go up if you knew you were working with a really
  tiny viewBox and needed a lot of precision, or down if you were working on a giant viewBox.
• Minify: We’re exporting for the web, so, yes.
• Responsive: On means “don’t put width and height attribute”. Off
  means do. It actually might be smart leaving this off (see here).

In SVG Options, choose settings suitable for your artwork from the CSS, Font, and other menus.

Select Minify to generate SVG code with minimal IDs, indents, lines, and white spaces.

Click OK.

See SVG to learn more about SVG
options.

Note: After exporting SVG code, don’t reopen in Illustrator to edit further. Instead, open the original Illustrator
(.ai) document and export to SVG again.

https://css-tricks.com/illustrator-to-svg/

Let’s say you created a lovely vector illustration in Adobe Illustrator. Or you’ve used Illustrator to finesse
some existing graphics. Or for literally any reason at all, you have a file open in Adobe Illustrator that you
ultimately want to use on the web as SVG.

There are several different ways of getting SVG out of Illustrator, each one a bit different. Let’s take a look.

TL;DR: Exporting, like File > Export > Export As… SVG then optimizing is your best bet for
the web.

The “Save As…” Method

Illustrator supports SVG as a first-class file format. You can File > Save As… and choose
“SVG” as an option, as an alternative to the default .ai file format.

Using Edit > Save As… in Illustrator

There is even a button in the Save SVG options that come up called “SVG Code…” you can click to have Illustrator
show you the code before saving it, presumably for copy-and-paste purposes.

If you search the web a bit about the differences between saving in different formats from Illustrator, you’ll
find plenty of generic information telling you that SVG is for use on THE WORLD WIDE WEB, so if that’s where you
intend to use this graphic, that’s the format you should save in.

Be careful here. Saving as SVG from Illustrator is fine, but the file is absolutely not ready
for direct use on the web. When you “Save As…” from Illustrator as SVG, Illustrators primary concern is that you
can open that file again in Illustrator just as you left it.

For example, Illustrator has proprietary features that aren’t a part of SVG. A simple example: guides. You won’t
lose your guides saving as SVG this way, they are preserved just fine. But guides are meaningless in SVG on the
web, so you’d be sending useless data if you use SVG saved this way directly on the web.

The file size of “Save As…” saved Illustrator SVG’s can be several orders of magnitude larger than a really
web-ready version. Take a look at the CSS-Tricks logo “Save As…”‘d and one exported for the web.

410 KB for the “Save As…” version vs. 3 KB
for the exported version.

It’s not entirely clear to us why “Save As…”ing as SVG would be a good idea. You may just want to keep files as
.ai until you want to actually export for the web. Or if you do save as SVG, you might as well use
the “Preserve Illustrator Editing Capabilities” checkbox and use a naming convention that is clear this is an
“original” file, not a web-ready one.

Wait, “exported version”? Let’s look at that next.

The “Export As” Method

File > Export > Export As… is very different. You are “exporting”, and the implication is
that the file that is generated is no longer an Illustrator-friendly and editable file, but a new file
specifically for some other purpose.

JPG is one of the options, for example. You wouldn’t expect to be able to edit your vector art after exporting it
as a JPG.

SVG is an option here too. The output is vastly different than “Save As…”. Exported SVGs actually are pretty
close to web-ready. There is no weird doctype, loads of metadata, or proprietary Illustrator stuff. Exported SVG
likely will not open in Illustrator in exactly the same way it was in the original file.

You’ll get a minimal export options screen, like this:

The SVG Options when exporting SVG.

The options shown there are good defaults. Quick overview:

• Styling: “Presentation Attributes” means stuff like fill: red; rather than “Inline Styles”
  which means style=”fill: red;”. Presentation attributes are easier to override in CSS. Inline styles provide
  more style resilience. There is also an option to export styles in a <style> block within
  the SVG, which may be efficient on SVG with lots of similar elements.
• Font: “SVG” means to use elements (and friends), which is extremely efficient, provided the
  fonts you’ve used are available on the web site you intended to use it on. “Convert to Outlines” will turn
  the text into vector shapes on export, making sure it will look exactly right, but losing efficient,
  accessibility, searchability, and copy-ability.
• Images: “Link” means that if there happens to be raster graphics within the SVG, it will
  link out to them rather than embedding them within the SVG, versus “Embed”ding them.
• Object ID’s: Unique ensures that every ID is unique (good for the web), but you also have
  the option to make them very short (“Minimal”) or be based on layer names.
• Decimal: 2 is probably fine. You’d only go up if you knew you were working with a really
  tiny viewBox and needed a lot of precision, or down if you were working on a giant viewBox.
• Minify: We’re exporting for the web, so, yes.
• Responsive: On means “don’t put width and height attribute”. Off
  means do. It actually might be smart leaving this off (see here).

Exporting this way is definitely good for the web. Although SVGO can still squeak a little bit more efficiency
out of it yet, depending on the graphic of course.

The “Export for Screens” Method

Since version CC 2017, Illustrator has an File > Export > Export for Screens… method built
specifically for exporting for digital devices. I’d say “the web”, but it has features for exporting for iOS and
Android, so “Screens”, as they say, is appropriate.

This brings up an options dialog allowing us to select our artwork in different ways and exports the parts we
want in the formats we want.

The “Export for Screens” options screen

This is really convenient UI! We can export just parts of our illustration in not only SVG, but other formats as
well, at the same exact time. Picture an icon system. 20 artboards in a single document, and with one command
you export all of them as SVG and multiple resolutions of PNG. Pretty nice.

Under the hood, it appears to be using the same system as “Export”, so you’ll get web-optimized output.

Artboards is one way of splitting up artwork to be exported separately. There is also an Asset Export panel that
allows you to drag-and-drop bits of artwork intended to be output separately.

The “Copy Directly from the
Artboard” Method

Speaking of selecting individual bits of artwork intended to be used as SVG, there is a slightly-lesser-known way
to extract bits, and that’s as simple as Edit > Copy.

After copying, your clipboard will have inline SVG code on it that you can paste as text.

The code that you get is slightly different than any method we’ve looked at so far. It’s closest to the “Save
As…” format though, in that you get the XML doctype and such. It’s not the web-optimized format we get from
exporting. It does have it’s own viewBox cropped exactly to the elements edges.

If you use this to drop SVG right into your HTML, plan to do a little manual code cleanup.

Now that you have the SVG…

… now what?

• Perhaps you’re gathering individual SVG icon files for use in an SVG icon system. As in, using a
  build tool to process them into a single file full of <symbol>s to
  <use>.
• Perhaps you needed the .svg to use as an <img>.
• Perhaps you needed the .svg to use as a background-image in CSS.
• Perhaps you’re going to drop the SVG code into HTML directly as inline SVG.

There are many ways to use SVG, but that always starts with
getting the SVG to work with in the first place.

https://css-tricks.com/svg-sprites-use-better-icon-fonts/

I’ve been a big proponent of icon fonts. Lots of sites really need a system for icons, and icon fonts offer a
damn fine system. However, I think assuming you’re good with IE 9+, using inline SVG and the
<use> element to reference an icon is a superior system.

First let’s cover how it works.

A nice way to handle your icons is to have a folder full of .svg files.

That’s one of the cool things about working
with SVG – they are the source files.

They can be colored, not colored, multiple shapes, sizes, whatever.

You can let Illustrator (or whatever) save it however, with all the cruft that comes along for the ride:

<?xml version="1.0" encoding="utf-8"?>
<!-- Generator: Adobe Illustrator 16.0.4, SVG Export Plug-In . SVG Version: 6.00 Build 0)  -->
<!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.1//EN" "http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd">
<svg version="1.1" id="Layer_1" xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink" x="0px" y="0px"
	 width="100px" height="100px" viewBox="0 0 100 100" enable-background="new 0 0 100 100" xml:space="preserve">
<g>
	<path d="M50.049,0.3c14.18,0.332,25.969,5.307,35.366,14.923S99.675,36.9,100,51.409c-0.195,11.445-3.415,21.494-9.658,30.146 - yadda yadda yadda"/>
</g>
</svg>

Combine the .svg files

You can manually do this if you want. I’ve done it. You don’t even have to look at the final file. Just call it
svg-defs.svg or something.

It should just be an <svg> tag, with a <defs> tag (which just means you are
defining stuff to use later), and then a bunch of <g> (group) tags. Each
<g> tag will have a unique ID, and will wrap all the paths and whatnot for each icon.

<svg>
  <defs>

    <g id="shape-icon-1">
      <!-- all the paths and shapes and whatnot for this icon -->
    <g>

    <g id="shape-icon-2">
      <!-- all the paths and shapes and whatnot for this icon -->
    <g>

    <!-- etc -->

  </defs>
</svg>

Turns out <symbol> is probably a better choice than <g>. Read all about it!

Again you can do that by hand, but of course that’s a bit laborious. Fabrice Weinberg has created a Grunt plugin
called grunt-svgstore that automates this.

If you’ve never used Grunt, you can do it. Here’s a screencast to get you
started.

You can install it with:

npm install grunt-svgstore --save-dev

Make sure the task is available with:

grunt.loadNpmTasks('grunt-svgstore');

And then in the config:

svgstore: {
  options: {
    prefix : 'shape-', // This will prefix each <g> ID
  },
  default : {
      files: {
        'dest/svg-defs.svg': ['svgs/*.svg'],
      }
    }
  }
},

In the output file, svg-defs.svg, each icon (whatever paths and stuff from the source .svg file)
will be wrapped up in a <g> tag with a unique, prefixed ID, and the file name (minus the
.svg). Like:

<g id="shape-codepen">

Inject that SVG at the top of the
document

Literally include it, like:

<!DOCTYPE html>
<html lang="en">

<head>
  ...
</head>

<body>
  <?php include_once("processed/svg-defs.svg"); ?>

Or however you want to do that.

It’s gotta be at the top, sadly, as there is a Chrome bug in which this isn’t going
to work if defined later. Although… there is more to this story because as I type these words, the theme this
very site is using has the icons defined at the bottom of the document and it works. Ughkgh confusing.

Use the icons wherever

Now you can use them wherever! Like:

<svg viewBox="0 0 100 100" class="icon shape-codepen">
  <use xlink:href="#shape-codepen"></use>
</svg>

Note that grunt-svgstore is now using
<symbol> so you don’t even need to use the viewBox!

Make sure you use those class names on the svg to size it.

/* Do whatever makes sense here.
   Just know that the svg will be an
   enormous 100% wide if you don't
   reign in the width. */
.icon {
  display: inline-block;
  width: 25px;
  height: 25px;
}

Yay: you can style them (and
their parts) with CSS

One of the reasons we loved icon fonts is the ability to style them with CSS. This technique one-ups that in that
we do everything we could there, and more, because:

1. We can style all the separate parts
2. SVG has even more things you can control, like special filters and strokes

The svg is (kinda) in the DOM, so JavaScript too. Here’s some styling possibilities and a demo of this all at
work:

Another way: IcoMoon

IcoMoon, which is known for producing icon fonts, actually does a fantastic
job of producing SVG sprites as well. After selecting all the fonts you want, click the SVG button on the bottom
and you’ll get that output, including a demo page with the inline SVG method.

Browser Support

On the browser support front, the danger zones are IE 8 and down, Safari 5 and down, iOS 4.3 and down, and
Android 2.3 and down. But if your policy is “the last two major versions” – you’re looking at pretty much 100%
support.

Remember that icons can be used as a supporting role only, like always accompanied by a word. If that’s the case,
support isn’t too big of a deal. If these are stand-alone, and non-display would make the site unusable, that’s
a big deal.

I probably would go for icon fonts, as the support there is much deeper. Just make sure you do it up right.

This is going to get a lot better

Ideally we’d be able to do this:

<svg viewBox="0 0 100 100" class="icon shape-codepen">
  <use xlink:href="/images/svg-defs.svg#shape-codepen"></use>
</svg>

This does work in some browsers, meaning you could skip the include at the top of the document. Doing it
this way means an extra HTTP request, but that means you can utilize caching more efficiently (not bloat
document caching). In testing, Jonathan Neal discovered you need to have the xmlns attribute on the
<svg> for it to work:

<svg xmlns="http://www.w3.org/2000/svg">

But even then, no support in any IE. Unless you wanted to swap out the whole
<svg><use> with an <object>, which does work. Jonathan Neal again figured this out:

/MSIE|Trident/.test(navigator.userAgent) && document.addEventListener('DOMContentLoaded', function () {
  [].forEach.call(document.querySelectorAll('svg'), function (svg) {
    var use = svg.querySelector('use');

    if (use) {
      var object = document.createElement('object');
      object.data = use.getAttribute('xlink:href');
      object.className = svg.getAttribute('class');
      svg.parentNode.replaceChild(object, svg);
    }
  });
});

His demo now also has a method which makes an Ajax request for
the contents and injects that, which allows the fills to work in IE 9. Not as efficient, but more like a
polyfill.

I imagine someday straight up <svg><use> linking right to the .svg will be the way to
go. Or even perhaps <img> working with URL fragment identifiers on the SVG.

Browsers treat <use> like the shadow DOM:

Right now, we can target, say, an individual <path> with CSS, like:

.targetting-a-path {
  fill: red;
}

But that will affect all instances of that path. You’d think you could do:

svg.shape-version-2 .targetting-a-path {
  fill: red;
}

But that doesn’t work. It crosses that shadow DOM boundary. Ideally you’d use the “hat” selector to break that:

svg.shape-version-2 ^ .targetting-a-path {
  fill: red;
}

But that’s not supported yet either and it’s not entirely clear if that’s exactly how that will work or not.

“Versus” icon fonts

Vector-based: tie

Style with CSS: slight edge to SVG sprites (targeting parts, SVG specific styling like strokes)

Weird failures: SVG seems to just work (when supported). Icon fonts seem to fail in weird ways.
For instance, you map the characters to normal letters, then the font loading fails and you get random
characters abound. Or you map to “Private Use Area” and some browsers decide to re-map them to really weird characters like
roses, but it’s hard to replicate. Or you want to host the @font-face files on a CDN, but that’s
cross-origin and Firefox hates that, so you need your server to serve the right cross-origin headers, but your
Nginx setup isn’t picking that up right, SIGH. SVG wins this one.

Semantics: Not a huge deal, but I think an <svg> makes a bit more sense for
an image than a <span>.

Accessibility: Maybe someone can tell me? Can we/should we give the <svg> a
title attribute or something? Or a <text> element inside that we visually hide?
Update: the <title> element might do. Or perhaps the
<desc> element as used in this SVG access
spec.

Ease of use: Tools like Fontello and IcoMoon are pretty good for an icon font workflow, but the folder-full-of-SVGs
with Grunt squishing them together for you is even easier, I think.

Ian Feather posted an
article about why they switched away from icon fonts as well and I agree with every single point.

https://www.ianfeather.co.uk/ten-reasons-we-switched-from-an-icon-font-to-svg/

Ten
reasons we switched from an icon font to SVGA Lonely Planet project

Posted on Jan 3, 2014 | Comments

We use a lot of icons on lonelyplanet.com and
recently went through the task of transferring them from an icon font to SVG files. I wanted to share why we did
this along with some of the drawbacks to SVG and how we got around them.

1. Separation of concerns

We use a custom font on lonelyplanet.com and we used to
bundle the icons into the same file, storing the glyphs within the Private Unicode Area. This was great because
it meant one less HTTP request to fetch the icons but we also felt that it limited our flexibility in how we
prioritised resource loading.

We don’t consider our font to be critical to the user’s experience and only a small subset of our icons are
actually deemed critical. We try to load non-critical assets after the page content and this was something we
weren’t able to do previously.

Breaking the critical icons out from the font and the rest of the icons allowed us to be more granular in how we
delivered them to the user.

Counter argument

“You don’t have to bundle the font and the font icons together, you could serve two separate fonts.”

We could do this instead and it’s something we probably would have done had we stuck with the font-face solution.

2. Some devices don’t
honour the Private Unicode Area

I’d heard rumours about devices overriding glyphs in the private unicode area and using them to serve emoji but I
hadn’t seen it happen until recently. Emoji was historically stored in the private unicode area, but at
different ranges, so it would make sense that there could be conflicts.

I can’t remember which device I was testing on but I saw one of our tick icons replaced with a multi-colour
printer. The page looked amateurish and broken and certainly gave us impetus to make this transition.

EDIT 28 SEPTEMBER 2014

There is an example of this, alongside some other excellent points, over at css-tricks.

Chris Coyier also collated an incredible compendium of SVG knowledge, A Compendium of SVG Information which should be
the default place to go for svg information.

3. Black squares and crosses on
opera mini

Font face support and detection is historically quite tricky to get right. I’m sure you’ve all seen this image of
font awesome rendering on opera mini:

I won’t go over the intricacies of this problem as Opera Mini support and many other platforms have been covered
very well in this
article by @kaelig. I think what is really important
though, beyond Opera Mini, is that this highlights a blind spot that we’re not able to control. We can’t test on
every device so we should use techniques that are more likely to render consistently.

We don’t get a huge amount of traffic from Opera Mini at the moment but we’re a travel company serving people in
all conditions on all bandwidths so we want to do better than that. With SVG and PNG we feel more confident that
users won’t get a broken and confusing page.

4. Chrome support
for font-icons has been terrible recently

Chrome Canary and Beta were hit with a fairly horrible font
bug recently. If you haven’t yet noticed the bug, fonts have been unloading and reverting to a system
font after the page has experienced a period of inactivity.

When a font unloads and you’re left with the text served as Georgia it can be a little annoying. The page is
still very usable though. If the same font is responsible for serving the icons then suddenly the page is
littered with black squares and looks broken.

This bug was introduced during our transition to SVG. It was a relief to cut over just as we were starting to get
our first bug reports about it.

Counter argument

Those bugs haven’t made it to a stable build of Chrome.

EDIT 28 SEPTEMBER 2014

These bugs did make it to stable, but have long since been fixed.

5. Crisper icons in Firefox

We’ve found that our font renders at a slightly stronger weight in Firefox than in other browsers. This is ok for
text (although not great) but for icons it can make the entire page look a bit unloved and clumsy. By using SVG
we are able to normalise the look and feel of our icons cross browser.

EDIT 28 SEPTEMBER 2014

Font weights can be normalised by applying -moz-osx-font-smoothing: grayscale;

6. You don’t always have to
use generated content.

If you want to use font-icons in css you need to declare them using the content property in generated content.
Sometimes you might find yourself having to complicate your code to make this possible i.e. because you are
already using the :before and :after pseudo elements on the element or because the element doesn’t support
generated content.

In that case you could choose to render it inline but you then end up with html entities scattered through your
markup which can easily be lost or forgotten about within a large application.

This problem is removed with SVG as you are not limited to generated content and can render them as a background
image on any element.

7. Less fiddly to position

Admittedly this may be a result of how we created and managed our icon glyphs but we always found them awkward to
position exactly how we wanted (and in a consistent fashion cross browser). We resorted to line height hacks and
absolute/relative positioning to get them just right and it was difficult to come up with an abstraction that
worked consistently.

With SVG we’ve found the placement much more willing. We use background-size: cover and resize the element to
ensure consistency across browsers.

8. Multi-colour icons

Font icons are well known to have a single colour limitation. SVGs, on the other hand, can support multiple
colours as well as gradients and other graphical features.

We have always had to support multi-colour map icons and had previously used an additional PNG sprite alongside
our icon font. As a result of the move to SVG we were able to delete this sprite which meant one less request
for the user.

Counter argument

This can be accomplished using icon layering.

It is significantly more challenging to do so successfully though: if positioning one glyph correctly
cross-browser is tricky, it won’t get easier with two.

EDIT 28 SEPTEMBER 2014

If you can handle the more limited browser support associated with inline svg, you could have multiple colour
control alongside a strong architecture by using the “ element approach.

9. SVGs allow us to use
animation within our icons.

We haven’t yet utilised this feature but is likely something we will look in to now that we have made the jump.

10. It’s always felt like a hack.

Through a combination of all of the above, using font-face for icons has always felt like a hack to me. It is a
brilliant hack, no doubt, but it’s still a different asset type masquerading and being manipulated into
something greater.

What about the benefits of font-face?

Serving icons through font-face does have some benefits over SVG and we had to consider these in depth before
making the transition. The most pertinent benefits for font-face are browser support and colour flexibility.

Colour variations

The huge benefit to using an icon font is its flexibility. You have no limitation to the amount of
colour variations and can easily switch it depending on the current state (:hover, :focus, .is-active etc.).
This is a huge luxury and very useful for quick development. It was also the reason we resisted making the leap
to SVG for so long.

Our solution

There are a few solutions out there to provide this functionality although all of them have their own limitations
(for now). We finally came up with a technique which we were pretty happy with and which toed the line between
flexibility and resource size.

Grunticon is designed to declare each icon individually, thus avoiding having to use sprites. We followed suit
with this approach but, although we had one css selector per icon, we served each icon in six different colours.

As we were just duplicating the same icon multiple times within the same file, the file compressed down to the
size of just one icon (plus around 50 bytes for gzip pointers). This meant that we could have n colour
variations for each icon at almost no cost. Here’s an example of how
it works.

With this solution we had the flexibility back that we thought we would miss. By taking away total flexibility it
also brought the added benefit of reinforcing colour palette consistency, something that had gradually been lost
from our font icon implementation.

With this technique we could easily apply state-based changes to the icons by updating their background position.

It’s worth mentioning that in the future we may be able to remove the sprite altogether and use SVG Fragment Identifiers to change the
colour.

Browser support

Font icons work all the way back to IE8 whereas SVG does not. For our implementation we also required support
for background-size although this is fairly comparable to
SVG support.

Our solution

Grunticon handles legacy support right out of the box.
We ended up tweaking it in our implementation to serve just a subset of the icons (the critical ones, e.g. the
logo) to unsupported browsers. This meant that older browsers received a working page with the necessary icons
and newer browsers got the full range of iconography.

Was it worth it?

Both techniques are resolution independent, scalable and fairly lightweight so if you are using either it is good
for the user. We felt that on balance SVGs gave us more confidence in how our application would appear to each
user and that extra element of control was ultimately what it came down to.