Part of the Intro to SVG Reading List

One of the most intimidating experiences of learning can be found in simply looking at the SVG code created by a vector illustration application. There’s usually a lot of code there; the output from early versions of Adobe Illustrator will often look something like this:

<?xml version="1.0" encoding="utf-8"?>
<!-- Generator: Adobe Illustrator 18.0.0, 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"
     viewBox="0 0 500 500" enable-background="new 0 0 500 500" 
     width="500" height="500"
     xml:space="preserve">
<!-- Actual SVG code here  -->
</svg>

The good news is that most of this code is redundant or unnecessary, and can be removed. But before we do so, it’s important to understand just what we’re taking away.

  1. The first line is the XML prolog. SVG is an expression of XML, a “root language” that can communicate almost any information structure via tags. These tags are very much like the elements that you’re probably familiar with from : in the case of SVG, we’re using XML structure to communicate mostly graphical information.

    XML has a great deal of freedom: technically, you can create any kind of tags you like. However, this freedom comes at a cost: XML syntax is formal, rule-bound and rigorous. That means that XML tags must always be closed, attribute values always inside quotes, etc. The fact that the prolog is at the start expresses the fact that SVG is a “subset” or “expression” of XML; furthermore, that all the content in the document is written in Unicode. But these facts are already known or assumed by everything that touches a SVG file, including the browser, meaning the prolog can be removed.

  2. The next line is a comment. You’ll see that comments in SVG are written just like in HTML. In this case, the comment tells us the originating application for the document. We don’t need this information either, so it can be removed.

  3. The DOCTYPE declaration is intended to be used for validation of the SVG document, but as Mozilla says, leaving it in place “leads to more problems than it solves”. Unless you’re planning to validate the SVG document with a schema processor it should be eliminated.

  4. Now we get to the actual start of the SVG document: the <svg> tag, sometimes referred to as the “root svg element”. There are still several attributes that we can cut at this point, however.

SVG Versioning

Like most languages, SVG has gone through several versions from when the specification was first issued as version 1.0 in 1999. SVG 1.1 followed in 2001, but only updated the organization of the specification, and did not introduce any syntax changes.

You may also see several other versions of SVG, particularly when exporting from vector programs like Adobe Illustrator, including SVG Tiny and SVG Basic. Both of these are considered “subsets” of SVG 1.1 - referred to as “profiles” in the spec - and were intended for use on low-powered mobile platforms. If employed in an SVG document, you’ll see them appearing as values for a baseProfile attribute withim the <svg> tag.

Basic and Tiny might be considered “cut down” versions of the full SVG specification: SVG Tiny does not support styling or scripting, for example, and doesn’t expose it’s elements to the DOM. However, they also contained some innovations, such as new attributes like vector-effect.

As a general rule, both Tiny and Basic should be avoided, for several reasons:

  1. Neither provide any guarantee of better support on mobile (iOS has good support of SVG Basic, but Windows Mobile has none, for example).
  2. Modern implementations of SVG in browsers have incorporated most of the innovations from Tiny and Basic.
  3. The specification of Tiny and Basic has changed since most tools were built, meaning that the applications no longer export the correct profiles or syntax.
  4. The intended purpose of Tiny and Basic have been made largely irrelevant by the power and popularity of smartphones.

Without a version attribute on the <svg> element, a browser will always assume that your code is using the latest version of SVG. This has continued into SVG2, which will formally drop the attribute and take on the versioning approach of HTML5.

Weeding Out More Redundant Code

There's a litle more we can remove from the SVG document to make it lighter and easier to read without influencing how it renders in the browser:

  • The id added by Adobe Illustrator to the code sample we started with is only necessary if you are using the SVG code inline on an HTML page and referencing that unique root element with or CSS; in most cases, it can be removed.
  • The x and y attributes set the position of the SVG when it is nested; as it's very unlikely you're trying to do this, the attributes should be removed.
  • enable-background was intended to specify that any background for the root element could also be used by child elements (such as in a <filter> composition process). However, there's essentially no browser support for this, and it will not make a difference to your SVG, so it should be taken out.
  • The width and height may be removed, with the understanding that doing can lead to rendering issues in Internet Explorer. This needs to be addressed when choosing to make the SVG responsive.
  • The xml:space="preserve" is meant to signal the author’s intent as to how white-space edge-cases should be treated in the document, but browser support is poor. (If you need this feature, employ Illustrator or Inkscape's text-adjustment commands instead).

The Final SVG Code

At this point, our SVG document looks something like this: 

<svg xmlns="http://www.w3.org/2000/svg"
    xmlns:xlink="http://www.w3.org/1999/xlink"
    viewBox="0 0 500 500">
    <!-- SVG code here  -->
</svg>

I think you’ll agree that it’s a whole lot cleaner and easier to understand!

However, we’re not quite finished: there’s still the issue of those xmlms attributes in the <svg> element… which I’ll discuss in the next article.

Enjoy this piece? I invite you to follow me at twitter.com/dudleystorey to learn more.