SVG is a language for describing two-dimensional graphics in markup, with shapes as elements, geometry as attributes, and stylistic effects as attributes or properties. SVG allows for three types of graphic objects: vector graphic shapes (e.g., paths consisting of straight lines and curves), multimedia (such as raster images, video, and audio), and text. Graphical objects can be grouped, styled, transformed, and composited into previously rendered objects.
SVG documents can be interactive and dynamic. Animations can be defined and triggered either through scripting or by declarative animations. SVG defines the use of both SMIL animation elements and animation via CSS.
Sophisticated applications of SVG are possible by use of the Document Object Model (DOM), along with graphics-specific extension interfaces. A rich set of event handlers can be assigned to any SVG graphical object. Because of its compatibility and leveraging of other Web standards, features like scripting can be done on HTML and SVG elements simultaneously within the same Web page.
SVG is a language for rich graphical content. For accessibility reasons, if there is an original source document containing higher-level structure and semantics, it is recommended that the higher-level information be made available somehow, either by making the original source document available, or making an alternative version available in a format which conveys the higher-level information, or by using SVG's facilities to include the higher-level information within the SVG content. For suggested techniques in achieving greater accessibility, see Accessibility.
SVG was designed according to the principles of the Architecture of the World Wide Web [AWWW].
Web users, content authors, and implementers of both browsers and authoring tools all benefit from tight cohesion and interoperability of Web technologies, in terms of functionality and syntax. SVG 2.0 is a backwards-compatible extension and reformulation of SVG 1.1, with key features from SVG Tiny 1.2. SVG 2.0 is intended to work more seamlessly with other Web technologies, such as HTML 5, CSS, DOM, and other core features of the open Web platform. Advanced features of SVG, such as filters, gradients, clipping, and other effects are intended for use with HTML and other presentation languages, as well.
SVG 2.0 is a single stand-alone specification, but also a series of modules. These modules are intended as extensions of SVG 1.1 and SVG Tiny 1.2, providing an upgrade path to SVG 2.0 for existing implementations. The SVG 2.0 specification consists of the core language features, along with the functionality of the essential SVG modules. Many of the SVG modules are in developed in conjunction with the CSS Working Group, to provide a single underlying model with alternative syntaxes for the convenience of content authors.
New modules for SVG may be developed which are not part of SVG 2.0; as these modules are implemented and adopted, they are candidates for future versions of the core SVG specification.
Embedded devices, such as mobile phones, portable computing devices, televisions and set-top boxes, and other specialized systems, have become more powerful and sophisticated, and no longer need profiling. SVG 2.0 is designed for use across platforms and devices.
When applied to conformance, the term "SVG 2.0" refers to the set of features defined by this specification. If an implementation does not implement this specification completely, the user agent's conformance claims must state the specific set of features it implements.
A user agent may implement additional features on top of those defined in this specification, as described in the section on extending SVG. If those features conform to a specific SVG module, the user agent should identify the supported module.
If a user agent supports features not found in any SVG specification or module, the implementer of the user agent should communicate a feature request, along with their use cases and requirements, to the SVG Working Group, for possible standardization, in order to promote interoperability.
Special-purpose profiles, which incorporate some modules from this specification in combination with other features as needed to meet particular industry requirements, such as mapping, may be appropriate for future consideration.
SVG 2.0 is a backwards compatible upgrade to SVG 1.1 and SVG Tiny 1.2. Backwards compatibity means that content conforming to SVG 1.1 or SVG Tiny 1.2 will render the same in conforming SVG 2.0 user agents as it did in older conforming SVG implementations. A few key differences from earlier versions of SVG should be noted:
There is no DTD for SVG 2.0, and therefore no need to specify the DOCTYPE for an SVG 2.0 document (unless it is desired to use the internal DTD subset ([XML10], section 2.8, and [XML11], section 2.8), for purposes of entity definitions for example). Instead, identification is by the SVG namespace, plus the 'version' and 'baseProfile' attributes. In SVG 2.0, validation can be performed using the RelaxNG schema.
The namespace for SVG 2.0 is the same as that of SVG 1.0, SVG 1.1, and SVG Tiny 1.2
http://www.w3.org/2000/svg and is
mutable
[NSState]; names may be added over time
by the W3C SVG Working Group by publication in W3C Technical Reports.
Here is an example of an SVG 2.0 document:
Here is an example of defining an entity in the internal DTD subset. Note that in XML, there is no requirement to fetch the external DTD subset and so relying on an external subset reduces interoperability. Also note that the SVG Working Group does not provide a normative DTD for SVG 2.0 but instead provides a normative RelaxNG schema.
The MIME type for SVG is "image/svg+xml" (see
Media type registration for image/svg+xml).
It is recommended that SVG files have the extension ".svg" (all
lowercase) on all platforms. It is recommended that
gzip-compressed
SVG files have the extension ".svgz" (all lowercase) on all
platforms [RFC1952].
It is recommended that SVG files stored on Macintosh HFS
file systems be given a file type of "svg "
(all lowercase, with a space character as the fourth letter).
It is recommended that gzip-compressed
SVG files stored on Macintosh HFS file systems be given a file
type of "svgz" (all lowercase).
(See Conformance Criteria for more information about gzip-compressed SVG files transmitted over HTTP.)
SVG 2.0 leverages and integrates with other W3C specifications and standards efforts. By leveraging and conforming to other standards, SVG becomes more powerful and makes it easier for users to learn how to incorporate SVG into their Web sites.
The following describes some of the ways in which SVG maintains compatibility with, leverages and integrates with other W3C efforts:
SVG 2.0 is an application of XML and is compatible with both the Extensible Markup Language (XML) 1.1 [XML11] and Extensible Markup Language (XML) 1.0 (Third Edition) [XML10] Recommendations.
SVG 2.0 is compatible with both the Namespaces in XML 1.0 [XML-NS10] and the Namespaces in XML 1.1 [XML-NS] Recommendations.
SVG 2.0 utilizes XML Linking Language (XLink) [XLINK10] for IRI referencing and requires support for base IRI specifications defined in XML Base [XML-BASE].
SVG 2.0 uses the 'xml:id' attribute as defined in xml:id Version 1.0 [XMLID].
SVG 2.0 content can be generated using XSL Transformations (XSLT) Version 1.0 [XSLT] or Version 2.0 [XSLT2]. (See Styling with XSL.)
SVG 2.0 supports formatting properties drawn from CSS and XSL. (See SVG's styling properties).
SVG 2.0 includes a compatible subset of the Document Object Model (DOM) and supports many of the facilities described in Document Object Model (DOM) Level 3 Core [DOM3], including namespace support and event handling.
SVG 2.0 incorporates some features from the Synchronized Multimedia Integration Language (SMIL) 2.1 Specification [SMIL21], including the 'prefetch' and 'switch' elements, the 'systemLanguage' attribute, animation features (see Animation) and the ability to reference audio and video media (see Multimedia). SVG's animation features incorporate and extend the general-purpose XML animation capabilities described in SMIL 2.1. In addition, SVG 2.0 has been designed to allow SMIL 2.1 to use animated or static SVG content as media components.
SVG is compatible with W3C work on internationalization. References (W3C and otherwise) include: The Unicode Standard [UNICODE] and the Character Model for the World Wide Web 1.0 [CHARMOD]. (See Internationalization Support.)
SVG is compatible with W3C work on Web Accessibility [WAI]. (See Accessibility Support).
In environments which support the Document Object Model (DOM) Core [DOM3] for other XML grammars (e.g., XHTML 1.0 [XHTML]) and which also support SVG and the SVG DOM, a single scripting approach can be used simultaneously for both XML documents and SVG graphics, in which case interactive and dynamic effects will be possible on multiple XML namespaces using the same set of scripts.
When used in this specification, terms have the meanings assigned in this section.
A conditional processing attribute is one of the five attributes that may appear on most SVG elements to control whether or not that element will be processed. Those attributes are 'requiredExtensions', 'requiredFeatures', 'requiredFonts', 'requiredFormats' and 'systemLanguage'.
The current SVG document fragment of an element is the XML document sub-tree such that:
A given element may have no current SVG document fragment.
The decorated bounding box follows the definition for bounding box, with the exception that it takes into account not only the geometry, but also all geometry-based drawing operations that are marked in their definitions as contributing to this calculation.
The document begin for a given SVG document fragment is the time at which the document's timeline is considered to begin. It depends on the value of the 'timelineBegin' attribute:
load
event is triggered.
The document end of an SVG document fragment is the time at which the document fragment has been released and is no longer being processed by the user agent.
Indicates the position in the timeline relative to the document begin of a given document fragment. Document time is sometimes also referred to as presentation time. For additional information see the SMIL 2.1 definition of document time ([SMIL21], section 10.7.1).
The operation of painting the interior of a shape or the interior of the character glyphs in a text string.
A font represents an organized collection of glyphs in which the various glyph representations will share a common look or styling such that, when a string of characters is rendered together, the result is highly legible, conveys a particular artistic style and provides consistent inter-character alignment and spacing.
A glyph represents a unit of rendered content within a font. Often, there is a one-to-one correspondence between characters to be drawn and corresponding glyphs (e.g., often, the character "A" is rendered using a single glyph), but other times multiple glyphs are used to render a single character (e.g., use of accents) or a single glyph can be used to render multiple characters (e.g., ligatures). Typically, a glyph is defined by one or more shapes such as a path, possibly with additional information such as rendering hints that help a font engine to produce legible text in small sizes.
A graphics element is an SVG element that can cause graphics to be drawn onto the target canvas. Specifically, the following elements are graphics elements: 'animation', 'circle', 'ellipse', 'image', 'line', 'path', 'polygon', 'polyline', 'rect', 'text', 'textArea', 'use' and 'video'.
A graphics referencing element is a graphics element that uses a reference to a different document or element as the source of its graphical content. The following elements are graphics referencing elements: 'animation', 'foreignObject', 'image', 'use' and 'video'.
A host language is a syntax which incorporates one or more SVG document fragments by inclusion or by reference, and which defines the interactions between document fragments; an example of this is WICD Core 1.0, an XML framework which defines how XHTML, SVG, MathML, XForms, SMIL, and other syntaxes interact [WICD].
A value is in error if it is specifically stated as being "in error" or "an error" in the prose of this specification. See Error Processing for more detail on handling errors.
An element is inactive when it is outside the active duration or when it is paused. Aural aspects of elements which are inactive (e.g. audio, and the audio track of a video element) are silent. SMIL defines the behavior of inactive elements with respect to timing, events, and hyperlinking. See Modelling interactive, event-based content in SMIL, Paused Elements and Active Duration and Event Sensitivity ([SMIL21], sections 10.12.0 and 10.4.3).
An IRI reference is an Internationalized Resource Identifier with an optional fragment identifier, as defined in Internationalized Resource Identifiers [RFC3987]. An IRI reference serves as a reference to a resource or (with a fragment identifier) to a secondary resource. See References.
An invalid IRI reference is an IRI reference that is syntactically invalid, cannot be resolved to a resource or takes a form that is not allowed for a given attribute, as defined in Reference restrictions.
A lacuna value is a defined behavior used when an attribute or property is not specified, or when an attribute or property has an unsupported value. This value is to be used for the purposes of rendering, calculating animation values, and when accessing the attribute or property using the TraitAccess interface. As opposed to an XML default value, however, the attribute or property and its value are not visible in the DOM, and cannot be accessed with DOM methods (e.g. getAttribute). For lacunae which are properties, if the property is inherited and there is no inherited value (for example, on the root element), the lacuna value is the initial value as specified in the definition of that property ([CSS2], section 6.1.1). For non-inherited properties, the lacuna value is always the initial value.
Note that a lacuna value is distinct from the XML term default value, which uses DTD lookup to determine whether an attribute is required and what its value is, and inserts required attributes and their values into the DOM ([XML10], section 3.3.2). At the XML parser level, SVG 2.0 does not have default values; lacunae are part of the SVG application layer, and their values are derived from the UA.
A local IRI reference is an IRI reference that references a fragment within the same resource. See References.
A navigation attribute is an XML attribute that specifies the element to be focused when the user instructs the SVG user agent to navigate the focus in a particular direction or to set the focus to the next or previous element in the focus ring. Specifically, the following attributes are navigation attributes: 'nav-next', 'nav-prev', 'nav-up', 'nav-down', 'nav-left', 'nav-right', 'nav-up-left', 'nav-up-right', 'nav-down-left' and 'nav-down-right'. See Specifying navigation.
A non-local IRI reference is an IRI reference that references a different document or an element within a different document.
A media element is an element which defines its own timeline within its own time container. The following elements are media elements: 'animation', 'audio' and 'video'. See Multimedia.
A paint represents a way of putting color values onto the canvas. A paint might consist of both color values and associated alpha values which control the blending of colors against already existing color values on the canvas. SVG 2.0 supports two types of built-in paint: color and gradients.
A presentation attribute is an XML attribute on an SVG element which specifies a value for a given property for that element. See Styling.
A property is a parameter that helps specify how a document should be rendered. A complete list of the SVG properties can be found in the Attribute and Property Table appendix. Properties are assigned to elements in the SVG language by presentation attributes. See Styling.
The rendering tree is the set of elements being rendered, aurally or visually using the painters model, in an SVG document fragment. The following elements in the fragment and their children are part of the SVG document fragment, but not part of the rendering tree (and thus are not rendered):
The copies of elements referenced by a 'use' element, on the other hand, are not in the SVG document fragment but are in the rendering tree. Note that elements with zero opacity, or no 'fill' and no 'stroke', or with an 'audio-level' of zero, or with the 'visibility' property set to hidden, are still in the rendering tree.
The rootmost 'svg' element is the furthest 'svg' ancestor element that does not exit an SVG context.
Note that this definition has been carefully chosen to be applicable not only to SVG 2.0 (where the rootmost 'svg' element is the only 'svg' element, except when there is an 'svg' element inside a 'foreignObject') but also for SVG Full 2.0 and SVG that uses XBL [XBL2]. See also SVG document fragment.
A tree fragment that is not part of the DOM tree, but which is attached to a referencing element (e.g. 'use' element) in a non-parent-child relationship, for the purpose of rendering and event propagation. The shadow tree is composed as if it were deep-structure clone of the referenced element in the rendering tree. The shadow tree is kept in synchronization with the contents of the referenced element, so that any animation, DOM manipulation, or non-DOM interactive state occurring on the referenced element are also applied to all the referencing instances. In SVG 2.0, only a subset of all SVG DOM methods to access the shadow tree are available.
Also referred to as an "instance tree".
A shape is a graphics element that comprises a defined combination of straight lines and curves. Specifically, the following elements are shapes: 'circle', 'ellipse', 'line', 'path', 'polygon', 'polyline' and 'rect'.
Stroking is the operation of painting the outline of a shape or the outline of character glyphs in a text string.
An SVG context is a document fragment where all elements within the fragment must be subject to processing by an SVG user agent according to the rules in this specification.
If SVG content is embedded inline within parent XML (such as XHTML), the SVG context does not include the ancestors above the rootmost 'svg' element. If the SVG content contains any 'foreignObject' elements which in turn contain non-SVG content, the SVG context does not include the contents of the 'foreignObject' elements.
In SVG 2.0, an SVG context contains one SVG document fragment.
An SVG document fragment is the XML document sub-tree whose rootmost element is an 'svg' element (that is, the rootmost 'svg' element.)
An SVG document fragment consists of either a stand-alone SVG document, or a fragment of a parent XML document where the fragment is enclosed by the rootmost 'svg' element.
In SVG 2.0, the SVG document fragment must not contain nested 'svg' elements. Nested 'svg' elements are unsupported elements and must not be rendered. Note that document conformance is orthogonal to SVG document fragment conformance.
For further details, see the section on Conforming SVG Document Fragments.
An SVG element is an element within the SVG namespace defined by the SVG language specification.
The syncbase of an animation element timing specifier is the element whose timing this element is relative to, as defined in SMIL 2.1 ([SMIL21], section 10.7.1).
A text content element is an SVG element that causes a text string to be rendered onto the canvas. The SVG 2.0 text content elements are the following: 'text', 'textArea' and 'tspan'.
A text content block element is a text content element that serves as a standalone element for a unit of text, and which may optionally contain certain child text content elements (e.g. 'tspan'). SVG 2.0 defines two text content block elements: 'text' and 'textArea'.
A timed element is an element that supports the SVG timing attributes. The following elements are timed elements: 'audio', 'animate', 'animateColor', 'animateMotion', 'animateTransform', 'animation', 'set' and 'video'.
A transformation is a modification of the current transformation matrix (CTM) by providing a supplemental transformation in the form of a set of simple transformations specifications (such as scaling, rotation or translation) and/or one or more transformation matrices. See Coordinate system transformations.
A transformation matrix defines the mathematical mapping from one coordinate system into another using a 3x3 matrix using the equation [x' y' 1] = [x y 1] * matrix. See current transformation matrix (CTM) and Coordinate system transformations.
An unsupported value is a value that does not conform to this specification, but is not specifically listed as being in error. See the Implementation Notes for more detail on processing unsupported values.
The general definition of a user agent is an application that retrieves and renders Web content, including text, graphics, sounds, video, images, and other content types. A user agent may require additional user agents that handle some types of content. For instance, a browser may run a separate program or plug-in to render sound or video. User agents include graphical desktop browsers, multimedia players, text browsers, voice browsers; used alone or in conjunction with assistive technologies such as screen readers, screen magnifiers, speech synthesizers, onscreen keyboards, and voice input software [UAAG].
A user agent may or may not have the ability to retrieve and render SVG content; however, an SVG user agent must be able to retrieve and render SVG content.
In general, a coordinate system defines locations and distances on the current canvas. The current user coordinate system is the coordinate system that is currently active and which is used to define how coordinates and lengths are located and computed, respectively, on the current canvas. See initial user coordinate system and Coordinate system transformations.
User space is a synonym for user coordinate system.
A coordinate value or length expressed in user units represents a coordinate value or length in the current user coordinate system. Thus, 10 user units represents a length of 10 units in the current user coordinate system.
A viewport is a rectangular region within the current canvas onto which graphics elements are to be rendered. See the description of the initial viewport in the Coordinate Systems, Transformations and Units chapter.
In general, a coordinate system defines locations and distances on the current canvas. The viewport coordinate system is the coordinate system that is active at the start of processing of an 'svg' element, before processing the optional 'viewBox' attribute. In the case of an SVG document fragment that is embedded within a parent document which uses CSS to manage its layout, then the viewport coordinate system will have the same orientation and lengths as in CSS, with the origin at the top-left on the viewport. See The initial viewport and Establishing a new viewport.
Viewport space is a synonym for viewport coordinate system.
A coordinate value or length expressed in viewport units represents a coordinate value or length in the viewport coordinate system. Thus, 10 viewport units represents a length of 10 units in the viewport coordinate system.
Note: When this specification uses the term
'svg' element,
'path' element, or similar reference to
an SVG element defined within this specification, it is
referring to the element whose namespace URI is http://www.w3.org/2000/svg
and whose local name is the string in quotes (e.g., "svg" or "path").
An exception to this is the
'listener'
element, whose namespace URI is http://www.w3.org/2001/xml-events.
When referencing this specification as a whole or when
referencing a chapter or major section, use the
undated URI, http://www.w3.org/TR/SVG20/,
where possible. This allows the reference to always refer to
the latest version of this specification.
This section is informative.
This specification is meant to serve both as a guide to authors in creating SVG content, and as a detailed reference for implementors of browsers, viewers, authoring tools, content processing tools, and other user agents to create conforming interoperable implementations for viewing SVG documents or outputting robust SVG code. It is not intended as a comprehensive manual for authoring content, and it is expected that books, tutorials, and other materials based on this specification will be produced to appeal to different audiences. It is meant to serve as a definitive source for authors and users to reference when reporting bugs and feature requests to implementations.
When reading this specification, in order to gain a complete understanding of the syntax concepts, readers should reference the individual definitions for elements, attributes, and properties, but also consult the definitions list, the element, attribute, property tables, and for more technically adept readers, the RelaxNG schema. For understanding scripting in SVG, readers should consult the sections on Interactivity, Scripting, and the SVG DOM.