However, there are always little quirks of a language that some people think are straightforward while other, equally talented, developers have never heard of. So this chapter gives a quick review of topics that you might want to brush up on—if you don’t already know them.
An SVG is an image file. It is perfectly possible to only use it as an image file, the same way you would use other image formats, such as PNG or JPEG. You can create and edit an SVG in a visual editor. You can embed it in web pages as an image.
But SVG is more than an image. It is a structured document containing markup elements, text, and style instructions. While other image formats tell the computer which color to draw at which point on the screen, SVG tells the computer how to rebuild the graphic from its component parts. That has two main consequences:
The final appearance of an SVG depends on how well the software displaying it follows the SVG instructions. Cross-browser compatibility is often a concern.
It is easy to edit parts of an SVG—to add, remove, or modify particular pieces—without changing the rest. You can do this in your editor, but you can also do it dynamically in your web browser to create animated or interactive graphics.
Not only is an SVG a set of coded instructions for a computer, it is also a human-readable text file. You can edit your SVG in a text editor. Even better, you can edit SVG in a code editor with syntax highlighting and autocomplete!
The examples in this book all focus on the basic SVG code. You can, of course, use a visual editor to draw shapes, select colors, and otherwise fuss with the appearance of your graphic. But for full control, you will need to take a look at the actual code that the editor creates.
The SVG code you view in your text editor looks an awful lot like HTML code—full of angle brackets and attributes—but a standalone SVG file is parsed as an XML document. This means that your SVG can be parsed and manipulated by tools meant for XML in general. It also means that your web browser won’t display anything if you forget to include the XML namespaces or mix up an important detail of XML syntax.
Nonetheless, when you insert SVG code directly in HTML 5 markup, it is processed by the HTML parser. The HTML parser forgives errors (like missing closing tags or unquoted attributes) that would halt the XML parser (or most SVG-only graphics editors). But it also ignores any custom namespaces, downcases any unrecognized attribute or tag names, and otherwise changes things up in ways you might not expect.
The syntax for SVG was—for the most part—designed to make it easy to read and understand, not to make it compact. This can make certain SVG files seem rather verbose and redundant. However, it also makes SVG very suitable for gzip compression, which should always be used when serving SVG on the Web. It will usually reduce file sizes by more than half, sometimes much more. If storing a gzipped SVG on a regular file server, it is typical to use the .svgz extension.
SVG is also bloatable, which makes it squishable in another way. Most SVG editors add their own elements and attributes to an SVG file by giving them unique XML namespaces. A class of optimization tools has developed that will strip out code that does not affect the final result. Just be careful about the settings you use—optimizers can remove attributes you might want later if you’re manipulating the code yourself!
So what does all that code represent? Shapes, of course! (And text and embedded images, but we’ll get to those in a moment…) SVG has only a few different shape elements:
<path>. Nonetheless, those last three can be extensively customized to represent any shape you can imagine, to a certain degree of precision. The
<path>, in particular, contains its own coded language for describing the curves and lines that create that shape.
Each SVG is an image, but it is also a document, and that document can contain other images, using the
<image> element. The embedded images could be other SVG files, or they could be raster images such as PNG or JPEG. However, for security and performance reasons, some uses of SVG prevent those external images (and other external resources such as stylesheets or fonts) from being downloaded. In particular, external files will not be used when an SVG is displayed as an embedded image (
<img> element) or background image in an HTML page.
The final building block used in SVG is text. But text isn’t an alternative to graphics—the letters that make up that text are treated like another type of vector shape. Importantly for this book, text can be painted using the exact same style properties as vector shapes.
The core of all vector graphics (shapes or text) is that the end result can be defined using mathematical parameters (the XML attributes) to the browser’s SVG rendering functions for each element. The most pervasive mathematical concept in SVG is the coordinate system, used to define the position of every point in the graphic. You can control the initial coordinate system by setting a
viewBox attribute, and you can use coordinate system transformations to shift, stretch, rotate, and skew the grid for certain elements.
There are no limits on the coordinates you can give for your vector shapes, except for the practical limits of computer number precision. The only shapes displayed, however, are those that fit within the particular range of coordinates established by the
viewBox attribute. This range of coordinates is scaled to fit the available area (the “viewport”), with accommodations for mismatched aspect ratios controlled by the
You can create nested viewports with nested
<svg> elements or reused
<symbol> elements; in addition to providing regions of aspect ratio control, these redefine how percentage lengths are interpreted for child content. Other elements use
viewBox to create a scale-to-fit effect (as we’ll see when we get to the
<pattern> element in Chapter 11), although without re-defining percentages.
The structure of an SVG includes the basic shapes, text, and images that are drawn to the screen, and the attributes that define their geometry. But SVG can have more structure than that, with elements grouped into logical clusters. Those groups can be styled and their coordinate systems transformed. But they can also be given accessible names and descriptions to help explain exactly what the graphics represent.
SVG graphics can consist solely of XML, with all style information indicated by presentation attributes. However, these presentation styles can also be specified with CSS rules, allowing styles to be assigned by class or element type. Using CSS also allows conditional styles to depend on media features or transient states such as
The strict separation between geometric structure (XML attributes) and presentation style (presentation attributes or CSS style rules) has always been a little arbitrary. As SVG moves forward, expect the divide to collapse even more. The SVG 2 draft specifications upgrade many layout attributes to become presentation attributes. This opens these properties to all the syntactic flexibility CSS offers: classes of similar elements can be given matching sizes with a single style rule, and those sizes or layout can be modified with CSS pseudoclasses or media queries.
The SVG specifications define many unique properties and methods for SVG DOM elements. These make it easier to manipulate the geometry of a graphic mathematically. Support for SVG DOM in web browsers is not as good as one might hope, but certain methods—such as determining the length of a curved path—are indispensable for SVG designs.
In a dynamic SVG viewer (e.g., a web browser) with scripting support, you can use those scripts to create animated and interactive graphics. However, SVG also supports declarative means of interaction, whereby you define the scope of an entire interaction and the browser applies it with its own optimizations. There are two means of doing this:
Using animation elements in the markup, with a syntax borrowed from the Synchronized Multimedia Integration Language (SMIL)
Using CSS animations and transitions of presentation styles
At the time of writing, scripted animation is supported in all web browsers, but may be blocked for certain uses of SVG. Declarative animation (SMIL and CSS) is supported in most browsers, but not all (Internet Explorer being the most notable exception). In addition, browsers are starting to implement the new Web Animations API, which allows a script to define and trigger an animation that will then be run independently, similar to a declarative animation.