One of the most intimidating experiences of learningSVG 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.
- 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 familiar with fromHTML: 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 inUnicode. But these facts are already known or assumed by everything that touches a SVG file, including the browser, meaning the prolog can be removed.
- The next line is a comment. You’ll see that comments in SVG are writtenjust 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.
- 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.
- 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.
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 likeAdobe 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
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
As a general rule, both Tiny and Basic should be avoided in development, for several reasons:
- Neither provide any guarantee of better support on mobile (iOS has good support of SVG Basic, but Windows Mobile has none, for example).
- SVG 1.2 has incorporated most of the innovations in Tiny and Basic.
- The intended purpose of Tiny and Basic have been made largely irrelevant by the power and popularity of smartphones.
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
y attributes set the origin of the
viewBox , but as
0 are their default values, the attributes don’t need to be stated.
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, every browser assumes this anyway , making the attribute deprecated.
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.
xml:space="preserve" is meant to signal the author’s intent as to how white-space edge-cases should be treated in the document. In the vast majority of cases, the default value is fine… which means that this attribute can be removed.
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.