W3C

Scalable Vector Graphics (SVG) 2.0 Specification

W3C

This version:
Latest version:
Previous version:
Editors:
Erik Dahlström (Opera Software) <ed@opera.com>
Anthony Grasso (Canon, Inc.) <anthony.grasso@cisra.canon.com.au>
Chris Lilley (W3C) <chris@w3.org>
Cameron McCormack (Invited Expert) <cam@mcc.id.au>
Doug Schepers (W3C) <schepers@w3.org>
Authors:
See author list.

Please refer to the errata for this document, which may include some normative corrections.

This document is also available in these non-normative formats: a single-page version, a zip archive of HTML (without external dependencies), and a PDF. See also translations, noting that the English version of this specification is the only normative version.


Abstract

This specification defines the features and syntax for Scalable Vector Graphics (SVG) Tiny, Version 2.0, a language for describing two-dimensional vector graphics in XML, combined with raster graphics and multimedia. Its goal is to provide the ability to create a whole range of graphical content, from static images to animations to interactive Web applications. SVG 2.0 is a profile of SVG intended for implementation on a range of devices, from cellphones and PDAs to laptop and desktop computers, and thus includes a subset of the features included in SVG 1.1 Full, along with new features to extend the capabilities of SVG. Further extensions are planned in the form of modules which will be compatible with SVG 2.0, and which when combined with this specification, will match and exceed the capabilities of SVG 1.1 Full.

Status of this document

This section describes the status of this document at the time of its publication. Other documents may supersede this document. A list of current W3C publications and the latest revision of this technical report can be found in the W3C technical reports index at http://www.w3.org/TR/.

This is the of SVG 2.0.

This document has been reviewed by W3C Members, by software developers, and by other W3C groups and interested parties, and is endorsed by the Director as a W3C Recommendation. It is a stable document and may be used as reference material or cited from another document. W3C's role in making the Recommendation is to draw attention to the specification and to promote its widespread deployment. This enhances the functionality and interoperability of the Web.

The SVG Working Group working closely with the developer community, has produced an implementation report to prove the implementability of this specification. Previous drafts for this specification resulted in a number of comments which have been addressed by the SVG Working Group, with a Disposition of Comments available on the W3C SVG site. A list of changes made since the Proposed Recommendation Working Draft is available in Appendix T.

As described in the abstract, this specification represents the core for a set of modular extensions.

Please send questions or comments regarding the SVG 2.0 specification to www-svg@w3.org, the public email list for issues related to SVG. This list is archived and acceptance of this archiving policy is requested automatically upon first post. To subscribe to this list send an email to www-svg-request@w3.org with the word "subscribe" in the subject line.

This document has been produced by the SVG Working Group as part of the W3C Graphics Activity, following the procedures set out for the W3C Process. The authors of this document are listed at the end in the Author List section.

This document was produced by a group operating under the 5 February 2004 W3C Patent Policy. W3C maintains a public list of any patent disclosures made in connection with the deliverables of the group; that page also includes instructions for disclosing a patent. An individual who has actual knowledge of a patent which the individual believes contains Essential Claim(s) must disclose the information in accordance with section 6 of the W3C Patent Policy.

Authors

The authors of the SVG 2.0 specification are the people who participated in the SVG Working Group as members or alternates.

Authors:

Acknowledgments

The SVG Working Group would like to acknowledge the editors and authors of previous versions of the SVG specification, and the many people outside of the SVG Working Group who help with the process of developing the SVG specification. These people are too numerous to list individually, but are greatly appreciated. They include but are not limited to the early implementers of the SVG languages (including viewers, authoring tools, and server-side transcoders), developers of SVG content, people who have contributed on the www-svg@w3.org and svg-developers@yahoogroups.com email lists, other Working Groups at the W3C, and the W3C Team. SVG is truly a cooperative effort between the SVG Working Group, the rest of the W3C, and the public, and benefits greatly from the pioneering work of early implementers and content developers, and from public feedback.


Expanded Table of Contents


1 Introduction

Contents

1.1 About SVG

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].

1.2 SVG 2.0

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.

1.2.1 Conformance t the SVG specification

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.

1.3 Defining an SVG 2.0 document

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:

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.

1.4 SVG MIME type, file name extension and Macintosh file type

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.)

1.5 Compatibility with other standards efforts

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:

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.

1.6 Definitions

When used in this specification, terms have the meanings assigned in this section.

after-edge
Defined in the XSL Area Model ([XSL], section 4.2.3).
animation element
Using the various animation elements, you can define motion paths, fade-in or fade-out effects, and allow objects to grow, shrink, spin or change color. The following five elements are animation elements: 'animate', 'animateColor', 'animateMotion', 'animateTransform' and 'set'. Animation elements are further described in Animation elements.
basic shape
Standard shapes which are predefined in SVG as a convenience for common graphical operations. Specifically, any instance of the following elements: 'circle', 'ellipse', 'line', 'polygon', 'polyline' and 'rect'.
before-edge
Defined in the XSL Area Model ([XSL], section 4.2.3).
canvas
A surface onto which graphics elements are drawn, which can be real physical media such as a display or paper or an abstract surface such as a allocated region of computer memory. See the description of the canvas in the Coordinate Systems, Transformations and Units chapter.
bounding box
A bounding box is the tightest fitting rectangle aligned with the axes of that element's user coordinate system that entirely encloses it and its descendants. For details, see the description of the bounding box in the Coordinate Systems, Transformations and Units chapter.
conditional processing attribute

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'.

container element
An element which can have graphics elements and other container elements as child elements. Specifically, the following elements are container elements: 'a', 'defs', 'g', 'svg' and 'switch'.
current SVG document fragment

The current SVG document fragment of an element is the XML document sub-tree such that:

  • The sub-tree is a valid SVG document fragment.
  • The sub-tree contains the element in question.
  • All ancestors of the element in question in the sub-tree are elements in the SVG language and namespace.

A given element may have no current SVG document fragment.

current transformation matrix (CTM)
Transformation matrices define the mathematical mapping from one coordinate system into another using a 3x3 matrix using the equation [x' y' 1] = [x y 1] * matrix. The current transformation matrix defines the mapping from the user coordinate system into the viewport coordinate system. See Coordinate system transformations.
decorated bounding box

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.

descriptive element
An element, not itself in the rendering tree, which provides supplementary information about the container element or graphics element to which it applies (i.e., the described element or elements). Specifically, the following elements are descriptive elements: 'desc', 'metadata', and 'title'.
document begin

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:

  • If 'timelineBegin' is 'onLoad', then the document begin is the exact time at which the 'svg' element's load event is triggered.
  • Otherwise, if 'timelineBegin' is 'onStart', then the document begin is the exact time at which the 'svg' element's start-tag ([XML10, XML11], section 3.1) is fully parsed and processed.
document end

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.

document time

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).

fill

The operation of painting the interior of a shape or the interior of the character glyphs in a text string.

font

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.

glyph

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.

graphics element

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'.

graphics referencing element

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'.

host language

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].

in error

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.

inactive element

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).

IRI reference

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.

Invalid IRI reference

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.

lacuna value

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.

local IRI reference

A local IRI reference is an IRI reference that references a fragment within the same resource. See References.

navigation attribute

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.

non-local IRI reference

A non-local IRI reference is an IRI reference that references a different document or an element within a different document.

media element

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.

paint

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.

presentation attribute

A presentation attribute is an XML attribute on an SVG element which specifies a value for a given property for that element. See Styling.

property

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.

rendering tree

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.

rootmost 'svg' element

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.

shadow tree

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".

shape

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'.

stroke

Stroking is the operation of painting the outline of a shape or the outline of character glyphs in a text string.

SVG context

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.

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.

SVG element

An SVG element is an element within the SVG namespace defined by the SVG language specification.

SVG user agent
An SVG user agent is a user agent that is able to retrieve and render SVG content.
syncbase

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).

text content element

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'.

text content block element

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'.

timed element

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'.

transformation

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.

transformation matrix

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.

unsupported value

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.

user agent

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.

user coordinate system

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

User space is a synonym for user coordinate system.

user units

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.

viewport

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.

viewport coordinate system

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

Viewport space is a synonym for viewport coordinate system.

viewport units

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.

1.7 How to reference this specification

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.

1.8 How to use 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.


2 Concepts

Contents

This chapter is informative.

2.1 Explaining the name: SVG

SVG stands for Scalable Vector Graphics, an XML grammar for 2D vector graphics, usable as an XML namespace.

2.1.1 Scalable

To be scalable means to increase or decrease uniformly. In terms of graphics, scalable means not being limited to a single, fixed, pixel size. On the Web, scalable means that a particular technology can grow to a large number of files, a large number of users, a wide variety of applications. SVG, being a graphics technology for the Web, is scalable in both senses of the word.

SVG graphics are scalable to different display resolutions, so that for example printed output uses the full resolution of the printer and can be displayed at the same size on screens of different resolutions. The same SVG graphic can be placed at different sizes on the same Web page, and re-used at different sizes on different pages. SVG graphics can be magnified to see fine detail, or to aid those with low vision.

SVG graphics are scalable because the same SVG content can be a stand-alone graphic or can be referenced or included inside other SVG graphics, thereby allowing a complex illustration to be built up in parts, perhaps by several people. The use and font capabilities promote re-use of graphical components, maximize the advantages of HTTP caching and avoid the need for a centralized registry of approved symbols.

2.1.2 Vector

Vector graphics contain geometric objects such as lines and curves. This gives greater flexibility compared to raster-only formats (such as PNG and JPEG) which have to store information for every pixel of the graphic. Typically, vector formats can also integrate raster images and can combine them with vector information to produce a complete illustration; SVG is no exception.

Since all modern displays are raster-oriented, the difference between raster-only and vector graphics comes down to where they are rasterized; client side in the case of vector graphics, as opposed to already rasterized on the server. SVG provides hints to control the rasterization process, for example to allow anti-aliased artwork without the ugly aliasing typical of low quality vector implementations.

2.1.3 Graphics

Most existing XML grammars represent either textual information, or represent raw data such as financial information. They typically provide only rudimentary graphical capabilities, often less capable than the HTML 'img' element. SVG fills a gap in the market by providing a rich, structured description of vector and mixed vector/raster graphics; it can be used stand-alone, or as an XML namespace with other grammars.

2.1.4 XML

XML [XML10, XML11], a W3C Recommendation for structured information exchange, has become extremely popular and is both widely and reliably implemented. By being written in XML, SVG builds on this strong foundation and gains many advantages such as a sound basis for internationalization, powerful structuring capability, an object model, and so on. By building on existing, cleanly-implemented specifications, XML-based grammars are open to implementation without a huge reverse engineering effort.

2.1.5 Namespace

It is certainly useful to have a stand-alone, SVG-only viewer. But SVG is also intended to be used as one component in a multi-namespace XML application. This multiplies the power of each of the namespaces used, to allow innovative new content to be created. For example, SVG graphics may be included in a document which uses any text-oriented XML namespace — including XHTML. A scientific document, for example, might also use MathML [MATHML] for mathematics in the document. The combination of SVG and SMIL leads to interesting, time based, graphically rich presentations.

SVG is a good, general-purpose component for any multi-namespace grammar that needs to use graphics.

2.1.6 Scriptable

The combination of scripting and the HTML DOM is often termed "Dynamic HTML" and is widely used for animation, interactivity and presentational effects. Similarly SVG allows the script-based manipulation of the document tree using a subset of the XML DOM and the SVG uDOM.

2.2 Important SVG concepts

2.2.1 Graphical objects

With any XML grammar, consideration has to be given to what exactly is being modelled. For textual formats, modelling is typically at the level of paragraphs and phrases, rather than individual nouns, adverbs, or phonemes. Similarly, SVG models graphics at the level of graphical objects rather than individual points.

SVG provides a general path element, which can be used to create a huge variety of graphical objects, and also provides common basic shapes such as rectangles and ellipses. These are convenient for hand coding and may be used in the same ways as the more general path element. SVG provides fine control over the coordinate system in which graphical objects are defined and the transformations that will be applied during rendering.

2.2.2 Re-use

It would have been possible to define some standard, pre-defined graphics that all SVG implementations would provide. But which ones? There would always be additional symbols for electronics, cartography, flowcharts, etc., that people would need that were not provided until the "next version". SVG allows users to create, re-use and share their own graphical assets without requiring a centralized registry. Communities of users can create and refine the graphics that they need, without having to ask a committee. Designers can be sure exactly of the graphical appearance of the graphics they use and not have to worry about unsupported graphics.

Graphics may be re-used at different sizes and orientations.

2.2.3 Fonts

Graphically rich material is often highly dependent on the particular font used and the exact spacing of the glyphs. In many cases, designers convert text to outlines to avoid any font substitution problems. This means that the original text is not present and thus searchability and accessibility suffer. In response to feedback from designers, SVG includes font elements so that both text and graphical appearance are preserved.

2.2.4 Animation

Animation can be produced via script-based manipulation of the document, but scripts are difficult to edit and interchange between authoring tools is harder. Again in response to feedback from the design community, SVG includes declarative animation elements which were designed collaboratively by the SVG and SYMM Working Groups. This allows the animated effects common in existing Web graphics to be expressed in SVG.

2.3 Options for using SVG in Web pages

There are a variety of ways in which SVG content can be included within a Web page. Here are some of the options:

A stand-alone SVG Web page

In this case, an SVG document (i.e., a Web resource whose MIME type is "image/svg+xml") is loaded directly into a user agent such as a Web browser. The SVG document is the Web page that is presented to the user.

Embedding by reference

In this case, a parent Web page references a separately stored SVG document and specifies that the given SVG document should be embedded as a component of the parent Web page. For HTML or XHTML, here are three options:

  • The (X)HTML 'img' element is the most common method for using graphics in HTML pages. For faster display, the width and height of the image can be given as attributes. One attribute that is required is 'alt', used to give an alternate textual string for people browsing with images off, or who cannot see the images. The string cannot contain any markup. A 'longdesc' attribute lets you point to a longer description — often in HTML — which can have markup and richer formatting.

  • The (X)HTML 'object' element can contain other elements nested within it, unlike 'img', which is empty. This means that several different formats can be offered, using nested 'object' elements, with a final textual alternative (including markup, links, etc). The rootmost element which can be displayed will be used.

  • The (X)HTML 'applet' element which can invoke a Java applet to view SVG content within the given Web page. These applets can do many things, but a common task is to use them to display images, particularly ones in unusual formats or which need to be presented under the control of a program for some other reason.

Embedding inline

In this case, SVG content is embedded inline directly within the parent Web page. An example is an XHTML Web page with an SVG document fragment textually included within the XHTML.

External link, using the HTML 'a' element

This allows any stand-alone SVG viewer to be used, which can (but need not) be a different program to that used to display HTML. This option typically is used for unusual image formats.

Referenced from a CSS or XSL property

When a user agent supports Cascading Style Sheets, Level 2 [CSS2] styled XML content, or Extensible Stylesheet Language [XSL] Formatting Objects, and the user agent is a Conforming SVG Viewer, then that user agent must support the ability to reference SVG resources wherever CSS or XSL properties allow for the referencing of raster images, including the ability to tile SVG graphics wherever necessary and the ability to composite the SVG into the background if it has transparent portions. Examples include the 'background-image' ([CSS2], section 14.2.1) and 'list-style-image' ([CSS2], section 12.6.2) properties that are included in both CSS and XSL.


3 Interactivity

Contents

3.1 Introduction

SVG content can be interactive (i.e., responsive to user-initiated events) by utilizing the following features in the SVG language:

This chapter describes:

Related information can be found in other chapters:

3.2 Complete list of supported events

The following aspects of SVG are affected by events:

The following table lists all of the events which must be recognized and supported in SVG. The "Description" column describes the required conditions for the event to occur.

Event Type Description Animation event name Bubbles Cancelable uDOM interface
DOMFocusIn

Occurs when an element receives focus.

See the DOM 2 Events definition of DOMFocusIn ([DOM2EVENTS], section 1.6.1).

focusin Yes No UIEvent
DOMFocusOut

Occurs when an element loses focus.

See the DOM 2 Events definition of DOMFocusOut ([DOM2EVENTS], section 1.6.1).

focusout Yes No UIEvent
DOMActivate

Occurs when an element is activated, for instance, through a mouse click or a keypress.

See the DOM 2 Events definition of DOMActivate ([DOM2EVENTS], section 1.6.1).

activate Yes Yes UIEvent
click

Occurs when the pointing device button is clicked over an element. A click is defined as a mousedown and mouseup over the same screen location. The sequence of these events is: mousedown, mouseup, click. If multiple clicks occur at the same screen location, the sequence repeats with the detail attribute incrementing with each repetition.

See the DOM 2 Events definition of click ([DOM2EVENTS], section 1.6.2).

click Yes Yes MouseEvent
mousedown

Occurs when the pointing device button is pressed over an element.

See the DOM 2 Events definition of mousedown ([DOM2EVENTS], section 1.6.2).

mousedown Yes Yes MouseEvent
mouseup

Occurs when the pointing device button is released over an element.

See the DOM 2 Events definition of mouseup ([DOM2EVENTS], section 1.6.2).

mouseup Yes Yes MouseEvent
mouseover

Occurs when the pointing device is moved onto an element.

See the DOM 2 Events definition of mouseover ([DOM2EVENTS], section 1.6.2).

mouseover Yes Yes MouseEvent
mousemove

Occurs when the pointing device is moved while it is over an element.

See the DOM 2 Events definition of mousemove ([DOM2EVENTS], section 1.6.2).

mousemove Yes Yes MouseEvent
mouseout

Occurs when the pointing device is moved away from an element.

See the DOM 2 Events definition of mouseout ([DOM2EVENTS], section 1.6.2).

mouseout Yes Yes MouseEvent
mousewheel

Occurs when a rotational input device has been activated.

See the description of the MouseWheelEvent event for details.

none Yes Yes MouseWheelEvent
textInput

One or more characters have been entered.

See the Text events section below for details.

none Yes Yes TextEvent
keydown

A key is pressed down.

See the Key events section below for details.

none Yes Yes KeyboardEvent
keyup

A key is released.

See the Key events section below for details.

none Yes Yes KeyboardEvent
load

The event is triggered at the point at which the user agent finishes loading the element and any dependent resources (such as images, style sheets, or scripts). In the case the element references a script, the event will be raised only after an attempt to interpret the script has been made. Dependent resources that fail to load will not prevent this event from firing if the element that referenced them is still in the document tree unless they are designated as externalResourcesRequired. The event is independent of the means by which the element was added to DOM tree.

load No No Event
SVGLoad

This event is deprecated and is for backwards compatibility only, see notes below. The This event must be dispatched immediately after the load event is dispatched.

none No No Event
resize

Occurs when a document view is being resized. This event is only applicable to 'svg' elements and is dispatched after the resize operation has taken place. The target of the event is the 'svg' element.

resize Yes No Event
SVGResize

This event is deprecated and is for backwards compatibility only, see notes below. This event must be dispatched immediately after the resize event is dispatched.

none Yes No Event
scroll

Occurs when a document view is being shifted along the X or Y or both axis, either through a direct user interaction or any change on the currentTranslate property available on SVGSVGElement interface. This event is only applicable to 'svg' elements and is dispatched after the shift modification has taken place. The target of the event is the 'svg' element.

scroll Yes No Event
SVGScroll

This event is deprecated and is for backwards compatibility only, see notes below. This event must be dispatched immediately after the scroll event is dispatched.

none Yes No Event
SVGZoom

Occurs when the zoom level of a document view is being changed, either through a direct user interaction or any change to the currentScale property available on SVGSVGElement interface. This event is only applicable to 'svg' elements and is dispatched after the zoom level modification has taken place. The target of the event is the 'svg' element.

zoom No No Event
SVGRotate

Occurs when the rotation of a document view is being changed, either through a direct user interaction or any change to the currentRotate property available on SVGSVGElement interface. This event is only applicable to 'svg' elements and is dispatched after the rotation modification has taken place. The target of the event is the 'svg' element.

rotate No No Event
beginEvent

Occurs when a timed element begins.

See the SMIL 2.1 definition of beginEvent ([DOM2EVENTS], section 10.6.2).

beginEvent Yes No TimeEvent
endEvent

Occurs when a timed element ends.

See the SMIL 2.1 definition of endEvent ([DOM2EVENTS], section 10.6.2).

endEvent Yes No TimeEvent
repeatEvent

Occurs when a timed element repeats. It is raised each time the element repeats, after the first iteration.

See the SMIL 2.1 definition of repeatEvent ([DOM2EVENTS], section 10.6.2).

repeatEvent Yes No TimeEvent
loadstart

A load operation has begun.

See the description of the ProgressEvent interface for details on this event.

none No No ProgressEvent
progress

Progress has occurred in loading a given resource.

See the description of the ProgressEvent interface for details on this event.

none No No ProgressEvent
loadend

A load operation has completed.

See the description of the ProgressEvent interface for details on this event.

none No No ProgressEvent
SVGTimer

Occurs when the specified timer interval has elapsed for a timer. This event is triggered only by 'running' timers in the current global execution context of the SVG document (i.e. for timers which have been instantiated via the SVGGlobal interface and started via the start() method of the SVGTimer interface). The target of the event is the SVGTimer object itself. The event processing is limited to the at target phase.

See the description of the SVGTimer interface for more details.

none No No Event

Note that in order to unify event names with other W3C specifications, SVG 2.0 deprecates some of the SVG 1.1 event types. (The term "deprecate" in this case means that user agents which are compatible with both SVG 1.1 and SVG 2.0 must support both the old deprecated event names and the new event names. Content creators who are making content that targets SVG 2.0 should use the new event types, not the deprecated event types.) Specifically:

Details on the values of attributes on the event object passed to event listeners for the event types defined in DOM Level 2 Events can be found in the description for that event in that specification. For other event types, the values of the attributes are are described elsewhere in this specification.

3.3 User interface events

On SVG user agents which support interactivity, it is common for authors to define SVG documents such that they are responsive to user interface events. Among the set of possible user events are pointer events, keyboard events, and document events.

In response to user interface (UI) events, the author might start an animation, perform a hyperlink to another Web page, highlight part of the document (e.g. change the color of the graphics elements which are under the pointer), initiate a "roll-over" (e.g., cause some previously hidden graphics elements to appear near the pointer) or launch a script which communicates with a remote database.

The following example shows the use of a DOMActivate event to trigger an ECMAScript event handler:

3.4 Pointer events

Note: The W3C's Web Content Accessibility Guidelines (WCAG) advise content creators to create device-independent content; in particular, content should not require that the user has access to a pointer device.

User interface events that occur because of user actions performed on a pointer device are called pointer events.

Many systems support pointer devices such as a mouse, trackball, stylus or joypad. On systems which use a mouse, pointer events consist of actions such as mouse movements and mouse clicks. On systems with a different pointer device, the pointing device often emulates the behavior of the mouse by providing a mechanism for equivalent user actions, such as a button to press which is equivalent to a mouse click.

One difference between stylus-based pointers and mouse-based pointers is that for a mouse, the cursor always has a position; for a stylus which may be lifted, the cursor may only have a position when the stylus is tapped on the screen. Thus, content which assumes that all pointer devices will generate mouseover and mouseout events will not work on all devices.

3.5 Text events

User interface events that occur because of user actions that generate text are called text events. They are usually generated by a keyboard, but can also be generated by a different input method such as an IME (for Japanese text, for example), by speech input, etc. The event is dispatched whenever a string of Unicode characters is sent to the document and is thus independent of the input device or method used.

3.6 Key events

Note: The W3C's Web Content Accessibility Guidelines (WCAG) advise content creators to create device-independent content; in particular, content should not require that the user has access to a (full-size) keyboard.

User interface events that occur because of user actions that generate key presses (as opposed to text — for example, function keys, key presses for a game, etc.) are called key events.

3.7 Event flow

DOM Level 2 Events defines the event flow model ([DOM2EVENTS], section 2.0), which defines three phases in which event listeners in the document are triggered: capture, at target and bubbling. An SVG 2.0 user agent is not required to support the capture phase of the event flow model. If the capture phase is not supported:

3.8 Event dispatching

For each pointer event, text event or key event, the SVG user agent determines the target object of a given event. The target object must be the topmost graphics element or SVGElementInstance object whose relevant graphical content is under the pointer (for pointer events) or has focus (for text and key events) at the time of the event. (See property 'pointer-events' for a description of how to determine whether an element's relevant graphical content is under the pointer, and thus in which circumstances that graphics element can be the target object for a pointer event.) When an element is not displayed (i.e., when the 'display' property on that element or one of its ancestors has a value of none), that element must not be the target of pointer events.

The decision on whether to dispatch the event to the target object or to one of the target elements ancestors shall depend on the following:

If an event is defined to bubble ([DOM2EVENTS], section 2.0.3), bubbling occurs up to all direct ancestors of the target object. Descendant elements receive events before their ancestors. Thus, if a 'path' element is a child of a 'g' element and they both have event listeners for click events, then the event will be dispatched to the 'path' element before the 'g' element.

After an event is initially dispatched to a particular element, unless an appropriate action has been taken to prevent further processing, the event must be passed to the appropriate event handlers (if any) for that element's ancestors (in the case of event bubbling) for further processing.

3.9 Processing order for user interface events

The processing order for user interface events shall be as follows:

The 'use' element creates shadow content which can be the target of user interface events.

User interface events within the shadow content shall participate in the processing of user interface events in the same manner as if the shadow content were part of the main document. In other words, if shadow content contains a graphics element that renders above other content at the current pointer location, then it represents the topmost graphics element and will receive the pointer events before other elements. In this case, the user interface events bubble up through the target's ancestors, and then across the document border into the referencing element, and then through the ancestors of the referencing element. This process continues as necessary if there are multiple levels of nested shadow trees.

3.10 The 'pointer-events' property

In different circumstances, authors may want to control under what circumstances particular graphics element can become the target of pointer events. For example, the author might want a given element to receive pointer events only when the pointer is over the stroked perimeter of a given shape. In other cases, the author might want a given element to ignore pointer events under all circumstances so that graphics elements underneath the given element will become the target of pointer events.

For example, suppose a 'circle' with a 'stroke' of red (i.e., the outline is solid red) and a 'fill' of none (i.e., the interior is not painted) is rendered directly on top of a 'rect' with a 'fill' of blue. The author might want the 'circle' to be the target of pointer events only when the pointer is over the perimeter of the 'circle'. When the pointer is over the interior of the 'circle', the author might want the underlying 'rect' to be the target element of pointer events.

The 'pointer-events' property specifies under what circumstances a given graphics element can be the target element for a pointer event. It affects the circumstances under which the following are processed:

'pointer-events'
Value:   boundingBox | visiblePainted | visibleFill | visibleStroke | visible |
painted | fill | stroke | all | none | inherit
Initial:   visiblePainted
Applies to:   graphics elements
Inherited:   yes
Percentages:   N/A
Media:   visual
Animatable:   yes
Computed value:   Specified value, except inherit
boundingBox
The given element must be a target element for pointer events when the pointer is over the bounding box of the element.
visiblePainted
The given element must only be a target element for pointer events when the 'visibility' property is set to visible and when the pointer is over a "painted" area. The pointer is over a painted area if it is over the interior (i.e., 'fill') of the element and the 'fill' property is set to a value other than none or it is over the perimeter (i.e., 'stroke') of the element and the 'stroke' property is set to a value other than none.
visibleFill
The given element must only be a target element for pointer events when the 'visibility' property is set to visible and when the pointer is over the interior (i.e., 'fill') of the element. The value of the 'fill' property does not effect event processing.
visibleStroke
The given element must only be a target element for pointer events when the 'visibility' property is set to visible and when the pointer is over the perimeter (i.e., 'stroke') of the element. The value of the 'stroke' property does not effect event processing.
visible
The given element must only be a target element for pointer events when the 'visibility' property is set to visible and the pointer is over either the interior (i.e., 'fill') or the perimeter (i.e., 'stroke') of the element. The values of the 'fill' and 'stroke' do not effect event processing.
painted
The given element must only be a target element for pointer events when the pointer is over a "painted" area. The pointer is over a painted area if it is over the interior (i.e., 'fill') of the element and the 'fill' property is set to a value other than 'none' or it is over the perimeter (i.e., 'stroke') of the element and the 'stroke' property is set to a value other than none. The value of the 'visibility' property does not effect event processing.
fill
The given element must only be a target element for pointer events when the pointer is over the interior (i.e., 'fill') of the element. The values of the 'fill' and 'visibility' properties do not effect event processing.
stroke
The given element must only be a target element for pointer events when the pointer is over the perimeter (i.e., 'stroke') of the element. The values of the 'stroke' and 'visibility' properties do not effect event processing.
all
The given element must be a target element for pointer events whenever the pointer is over either the interior (i.e., 'fill') or the perimeter (i.e., 'stroke') of the element. The values of the 'fill', 'stroke' and 'visibility' properties do not effect event processing.
none
The given element must not receive pointer events.

For text elements, hit detection shall be performed on a character cell basis:

For raster images, hit detection shall either be performed on a whole-image basis (i.e., the rectangular area for the image is one of the determinants for whether the image receives the event) or on a per-pixel basic (i.e., the alpha values for pixels under the pointer help determine whether the image receives the event). The following rules must be adhered to:

Note that for raster images, the values of properties 'fill-opacity', 'stroke-opacity', 'fill' and 'stroke' do not effect event processing.

3.11 Magnification and panning

Magnification represents a complete, uniform transformation on an SVG document fragment, where the magnify operation scales all graphical elements by the same amount. A magnify operation has the effect of a supplemental scale and translate transformation placed at the rootmost level on the SVG document fragment (i.e. outside the rootmost 'svg' element).

Panning represents a translation (i.e., a shift) transformation on an SVG document fragment in response to a user interface action.

SVG user agents that operate in interaction-capable user environments are required to support the ability to magnify and pan.

Attribute definition:

zoomAndPan = "magnify" | "disable"

Can be specified on the 'svg' element. The attribute is intended for applications where SVG is used for both the content and for the user interface, e.g. a mapping application. The default zoom might move critical user interface components from view, confusing the user; disabling the default zoom, pan and rotate while providing zoom, pan and rotate controls for a smaller content area would give a better user experience. The effect of 'zoomAndPan' applies solely to user interface aspects, and must not disable script-initiated zooming and panning on the corresponding element.

The attribute value can be one of the following:

magnify
The lacuna value. If magnify, in environments that support user interactivity, the user agent must provide controls to allow the user to perform a "magnify" operation on the document fragment.
disable
If disable, the user agent shall in its default interaction mode disable any magnification and panning controls and not allow the user to magnify or pan on the given document fragment. The SVG user agent may provide another mode which continues to allow zoom and pan at user option.

Animatable: no.

3.12 Element focus

3.12.1 The 'focusable' attribute

In many cases, such as text editing, the user is required to place focus on a particular element, ensuring that input events, such as keyboard input, are sent to that element.

All renderable elements are required to be able to accept focus if specified by the author, including container elements (except 'defs'), graphics elements, 'tspan' and 'foreignObject'. A focusable container element may contain focusable descendants.

Attribute definition:

focusable = "true" | "false" | "auto"

Defines if an element can get keyboard focus (i.e. receive keyboard events) and be a target for field-to-field navigation actions. (Note: in some environments, field-to-field navigation can be accomplished with the tab key.)

The attribute value can be one of the following:

true
The element is keyboard-aware and must be treated as any other UI component that can get focus.
false
The element is not focusable.
auto

The lacuna value. Equivalent to 'false', except that it must be treated like 'true' for the following cases:

Animatable: yes.

3.13 Navigation

3.13.1 Navigation behavior

System-dependent input facilities (e.g., the tab key on most desktop computers) should be supported to allow navigation between elements that can obtain focus (i.e. elements for which the value of the 'focusable' attribute is 'true').

The document has the concept of a focus ring, which is the order in which elements obtain focus. By default the focus ring shall be obtained using document order. All focusable elements must be part of the default focus ring. A document's focus ring includes any focusable objects within shadow trees for 'use' elements. The focus attributes may be used to modify the default focus ring.

The SVG language supports a flattened notion of field navigation between focusable elements where an author may define field navigation between any two focusable elements defined within a given SVG document without regard to document hierarchy. For example:

    <rect xml:id="r1" focusable="true" .../>
    <g xml:id="g1" focusable="true">
      <circle xml:id="c1" focusable="true" .../>
    </g>

In the above example, the author may specify field-to-field navigation such the user can navigate directly from any of the three elements. Thus, assuming a desktop computer which uses the tab key for field navigation, the author may specify focus navigation order such that the tab key takes the user from "r1" to "c1" to "g1".

When navigating to an element that is not visible on the canvas the following rules shall apply:

SVG's flattened notion of field navigation shall extend to referenced content and shadow trees as follows:

Focus navigation shall behave as specified:

  1. When the document is loaded the focus is first offered to the SVG user agent.

  2. Once the SVG user agent releases focus, then focus passes to the entity that first matches the following criteria:

    1. the rootmost 'svg' element if it is focusable,
    2. the element referenced by the 'nav-next' attribute on the rootmost 'svg' element, if the attribute is present,
    3. the first focusable element in the document starting from the rootmost 'svg' element,
    4. the SVG user agent
  3. If the focus is held by an element in the document, then the next element in navigation order shall be the entity that first matches the following criteria:

    1. the element referenced by the 'nav-next' attribute on the focused element,
    2. the next focusable element in document order,
    3. the SVG user agent
  4. If the focus is held by an element in the document, then the previous element in navigation order shall be the entity that first matches the following criteria:

    1. the element referenced by the 'nav-prev' attribute on the focused element,
    2. the previous focusable element in document order,
    3. the SVG user agent

For stand-alone SVG documents, the SVG user agent must always have a currently focused object. If focus is not held by any object in the document tree, the SVG user agent must give focus to the SVGDocument object.

For SVG documents which are referenced by a non-SVG host document (e.g., XHTML), the SVG document may participate within the host document's focus ring, which would allow direct navigation from an SVG focusable element onto a focusable element within the host document. Other compound document specifications may define supplemental SVG focus navigation rules for situations when SVG content is used as a component within a compound document.

User agents should provide a mechanism for a user to escape from a focus ring. When the user activates this mechanism, the user agent should change focus to the user agent, sending the appropriate focusout event to the element currently in focus.

3.13.2 Specifying navigation

Navigation order can be specified using the ten navigation attributes defined below.

Attribute definitions:

nav-next,
nav-prev = "<FuncIRI>" | "auto" | "self"

Specifies the next element (when using 'nav-next') or previous element (when using 'nav-prev') in the focus ring.

The attribute value for 'nav-next' and 'nav-prev' can be one of the following:

<FuncIRI>
Specifies the element that must receive focus when navigation in the next direction (for 'nav-next') or previous direction (for 'nav-prev') is triggered. The specified element must be within the current SVG document fragment.
auto
The lacuna value. Means that the behavior shall be as if the attribute was not specified (navigation must follow the rules specified in Navigation behavior).
self
The focus must stay on the element itself.

Animatable: yes.

nav-up,
nav-up-right,
nav-right,
nav-down-right,
nav-down,
nav-down-left,
nav-left,
nav-up-left = "<FuncIRI>" | "auto" | "self"

Each of these eight attributes specifies an element to receive focus when navigating in a particular direction. For each of the attributes, the direction for which an element is being specified for navigation is suggested by the name of the attribute. The following table lists these directions explicitly:

Attribute name Direction
'nav-up' ↑ upward
'nav-up-right' ↗ up-and-rightward
'nav-right' → rightward
'nav-down-right' ↘ down-and-rightward
'nav-down' ↓ downward
'nav-down-left' ↙ down-and-leftward
'nav-left' ← leftward
'nav-up-left' ↖ up-and-leftward

The value for each of these attributes can be one of the following:

<FuncIRI>
Specifies the element that must receive focus when navigation in the given direction is triggered. The specified element must be within the current SVG document fragment.
auto
The lacuna value. Means that the behavior is left up to the SVG user agent.
self
The focus must stay on the element itself.

Animatable: yes.

This example illustrates how it is possible for an author to control the focus order between several focusable elements displayed on the canvas.

On a device which provides a 2-way navigation system (a TAB mechanism for instance), here are the interesting behaviors:

On a device which provides a 4-way navigation system (i.e. a joystick for instance), here are the interesting behaviors:

3.13.3 Specifying focus highlighting

Automated highlighting upon focus can be specified using the 'focusHighlight' attribute. This hint indicates whether the SVG user agent should highlight an element on focus. The highlighting method is implementation dependent and the SVG user agent should pick a method that works well for varying content. This attribute is available on all graphical and container elements.

focusHighlight = "auto" | "none"

Specifies whether a SVG user agent should highlight an element on focus.

The attribute value can be one of the following:

auto

The lacuna value. This indicates that the element should be highlighted on focus. The highlighting method is left up to the SVG user agent.

none

The SVG user agent should not highlight this element on focus.

Animatable: no.

In the above SVG example:

3.13.4 Obtaining and listening to focus programmatically

When the user agent gives an element focus it receives a DOMFocusIn event which has the new focused object as the event target and a DOMFocusOut event which has the previously focused object as the event target.

The SVGSVGElement interface has a setFocus method that puts the focus on the requested object. Calling setFocus with an element that is not focusable causes focus to stay on the currently focused object.

The SVGSVGElement interface has a moveFocus(short motionType) which moves current focus to a different object based on the value of motionType.

SVG user agents which support pointer devices such as a mouse must allow users to put focus onto focusable elements. For example, it should be possible to click on a focusable element in order to give focus.

Empty text fields in SVG theoretically take up no space, but they have a point or zero-width line segment that represents the location of the empty text field. SVG user agents should allow users with pointer devices to put focus into empty text fields by initiating a select action (e.g., a mouse click) at the location of the empty text field.

An author may change the field navigation order from a script by using the setTrait method to change the current value of navigation attributes on a given element (see Example below).


4 Linking

Contents

4.1 References

4.1.1 Overview

On the Internet, resources are identified using IRIs (Internationalized Resource Identifiers). For example, an SVG file called someDrawing.svg located at http://example.com might have the following IRI:

http://example.com/someDrawing.svg

An IRI can also address a particular element within an XML document by including an IRI fragment identifier as part of the IRI. An IRI which includes an IRI fragment identifier consists of an optional base IRI, followed by a "#" character, followed by the IRI fragment identifier. For example, the following IRI can be used to specify the element whose ID is "Lamppost" within file someDrawing.svg:

http://example.com/someDrawing.svg#Lamppost

Altering the 'xlink:href' attribute

If the 'xlink:href' attribute of an element in the tree is altered by any means (e.g. script, declarative animation) such that a new resource is referenced, the new resource must replace the existing resource, and must be rendered as appropriate. For specific effects on the scripting context when a 'script' element's 'xlink:href' attribute is altered, see Script processing.

4.1.2 IRIs and URIs

Internationalized Resource Identifiers (IRIs) are a more generalized complement to Uniform Resource Identifiers (URIs). An IRI is a sequence of characters from the Universal Character Set [UNICODE]. A URI is constructed from a much more restricted set of characters. All URIs are already conformant IRIs. A mapping from IRIs to URIs is defined by the IRI specification, which means that IRIs can be used instead of URIs in XML documents, to identify resources. IRIs can be converted to URIs for resolution on a network, if the protocol does not support IRIs directly.

Previous versions of SVG, following XLink, defined a IRI reference type as a URI or as a sequence of characters which must result in a URI reference after a particular escaping procedure was applied. The escaping procedure was repeated in the XLink 1.0 specification [XLINK10], and in the W3C XML Schema Part 2: Datatypes specification [SCHEMA2]. This copying introduced the possibility of error and divergence, but was done because the IRI specification was not yet standardized.

In this specification, the correct term IRI is used for this "URI or sequence of characters plus an algorithm" and the escaping method, which turns IRIs into URIs, is defined by reference to the IRI specification [RFC3987], which has since become an IETF Proposed Standard. Other W3C specifications are expected to be revised over time to remove these duplicate descriptions of the escaping procedure and to refer to IRI directly.

4.1.3 Syntactic forms: IRI and FuncIRI

IRIs are used in the 'xlink:href' attribute. Some attributes allow both IRIs and text strings as content. To disambiguate a text string from a relative IRI, the functional notation <FuncIRI> is used. This is simply an IRI delimited with a functional notation. Note: For historical reasons, the delimiters are "url(" and ")", for compatibility with the CSS specifications. The FuncIRI form is used in presentation attributes and navigation attributes.

SVG makes extensive use of IRI references, both absolute and relative, to other objects. For example, to fill a rectangle with a linear gradient, you first define a 'linearGradient' element and give it an ID, as in:

Example: 05_07.xml
<linearGradient xml:id="MyGradient">...</linearGradient>

You then reference the linear gradient as the value of the 'fill' property for the rectangle, as in the following example:

Example: 05_08.xml
<rect fill="url(#MyGradient)"/>

4.1.4 Reference restrictions

Some of the elements using IRI references have restrictions on them. Which kinds of IRI references that are allowed on each element is listed in the table below. In SVG, IRI references can be categorized as being one (or more) of the following five types:

For each of the above five IRI types, A – E, there is a column in the reference restriction table below indicating whether the given attribute is allowed to have a reference of the given form. An IRI reference that does not comply to the restrictions in the table below is an invalid IRI reference.

Element Referencing attribute A B C D E
An animation element 'xlink:href' Yes, see Identifying the target element for an animation for reference rules. No No No No
'discard' 'xlink:href' Yes, see Identifying the target element for an animation for reference rules. No No No No
'a' 'xlink:href' Yes, see Linking into SVG content. Yes, see Links out of SVG content. Yes Yes Yes
'use' 'xlink:href' Yes, but a 'use' element must not reference an 'svg' element. Yes, but the referenced fragment must not contain scripting, hyperlinking to animations or any externally referenced 'use' or 'animation' elements. No No No
'image' 'xlink:href' No No No Yes, but the 'image' element must reference content that is a raster image format. Yes, but the content within the data: IRI reference must be a raster image.
'animation' 'xlink:href' No No Yes No Yes
'prefetch' 'xlink:href' Yes Yes Yes Yes No
'audio' 'xlink:href' No No No Yes, depending on supported audio formats, indicated by the 'type' attribute. Yes
'video' 'xlink:href' No No No Yes, depending on supported video formats, indicated by the 'type' attribute. Yes
'foreignObject' 'xlink:href' No Yes No Yes Yes
'script' 'xlink:href' No No No Yes, but it must reference an external resource that provides the script content. Yes
'handler' 'xlink:href' Yes Yes No Yes, but it must reference an external resource that provides the script content. Yes
'listener' 'handler'
Yes No No No No
An element on which paint may be specified 'fill' Yes, only referencing a paint server, see Specifying paint. No No No No
An element on which paint may be specified 'stroke' Yes, only referencing a paint server, see Specifying paint. No No No No
An element on which navigation attributes may be specified A navigation attribute Yes, see Specifying navigation. No No No No
'font-face-uri' 'xlink:href' Yes, the reference must be to an SVG 'font' element. Yes, the reference must be to an SVG 'font' element. No No Yes
'mpath' 'xlink:href' Yes, only referencing a 'path' element. No No No No

Additionally, any IRI reference which cannot be resolved is an invalid IRI reference. Examples of reasons for an IRI reference to be unable to be resolved include:

Any required processing for an attribute with an invalid IRI reference is described in the attribute definition. Note that when the 'externalResourcesRequired' attribute has been set to 'true' on the referencing element or one of its ancestors, then an unresolved external IRI reference will result in special handling (see External resources).

A circular IRI reference is an error. Because SVG user agents may vary on when they first detect and abort a circular reference, conforming SVG document fragments must not rely upon circular references. Examples of circular references include:

It is recommended that, wherever possible, referenced elements be defined inside of a 'defs' element. Among the elements that are always referenced are 'linearGradient' and 'radialGradient'. Defining these elements inside of a 'defs' element promotes understandability of the SVG content and thus promotes accessibility.

4.1.5 IRI reference attributes

IRI references are normally specified with an 'href' attribute in the XLink [XLink] namespace. For example, if the prefix of 'xlink' is used for attributes in the XLink namespace, then the attribute is be specified as 'xlink:href'. The value of this attribute forms a reference for the desired resource (or secondary resource, if there is a fragment identifier).

The value of the 'href' attribute must be an Internationalized Resource Identifier.

If the protocol, such as HTTP, does not support IRIs directly, the IRI is converted to a URI by the SVG implementation, as described in section 3.1 of the IRI specification [RFC3987.

Because it is impractical for any application to check that a value is an IRI reference, this specification follows the lead of the IRI Specification in this matter and imposes no such conformance testing requirement on SVG applications.

If the IRI reference is relative, its absolute version must be computed by the method described in XML Base before use [XML-BASE].

Additional XLink attributes can be specified that provide supplemental information regarding the referenced resource.

Schema: xlinkattr
    <define name='svg.XLinkBase.attr' combine='interleave'>
      <optional>
        <attribute name='xlink:type' svg:animatable='true' svg:inheritable='false'>
          <value>simple</value>
        </attribute>
      </optional>
      <optional>
        <attribute name='xlink:role' svg:animatable='false' svg:inheritable='false'>
          <ref name='IRI.datatype'/>
        </attribute>
      </optional>
      <optional>
        <attribute name='xlink:arcrole' svg:animatable='false' svg:inheritable='false'>
          <ref name='IRI.datatype'/>
        </attribute>
      </optional>
      <optional>
        <attribute name='xlink:title' svg:animatable='false' svg:inheritable='false'><text/></attribute>
      </optional>
    </define>

    <define name='svg.XLinkHrefRequired.attr' combine='interleave'>
      <optional>
        <attribute name='xlink:href' svg:animatable='true' svg:inheritable='false'>
          <ref name='IRI.datatype'/>
        </attribute>
      </optional>
    </define>

    <define name='svg.XLinkBaseRequired.attr' combine='interleave'>
      <ref name='svg.XLinkBase.attr'/>
      <ref name='svg.XLinkHrefRequired.attr'/>
    </define>


    <define name='svg.XLinkActuateOnLoad.attr' combine='interleave'>
      <optional>
        <attribute name='xlink:actuate' svg:animatable='false' svg:inheritable='false'>
          <value>onLoad</value>
        </attribute>
      </optional>
    </define>

    <define name='svg.XLinkShowOther.attr' combine='interleave'>
      <optional>
        <attribute name='xlink:show' svg:animatable='false' svg:inheritable='false'>
          <value>other</value>
        </attribute>
      </optional>
    </define>


    <define name='svg.XLinkEmbed.attr' combine='interleave'>
      <optional>
        <attribute name='xlink:show' svg:animatable='false' svg:inheritable='false'>
          <value>embed</value>
        </attribute>
      </optional>
      <ref name='svg.XLinkActuateOnLoad.attr'/>
      <ref name='svg.XLinkBaseRequired.attr'/>
    </define>


    <define name='svg.XLinkRequired.attr' combine='interleave'>
      <ref name='svg.XLinkShowOther.attr'/>
      <ref name='svg.XLinkActuateOnLoad.attr'/>
      <ref name='svg.XLinkBaseRequired.attr'/>
    </define>


    <define name='svg.XLinkReplace.attr' combine='interleave'>
      <optional>
        <attribute name='xlink:show' svg:animatable='false' svg:inheritable='false'>
          <choice>
            <value>new</value>
            <value>replace</value>
          </choice>
        </attribute>
      </optional>
      <optional>
        <attribute name='xlink:actuate' svg:animatable='false' svg:inheritable='false'>
          <value>onRequest</value>
        </attribute>
      </optional>
      <ref name='svg.XLinkBaseRequired.attr'/>
    </define>

    <define name='svg.XLink.attr' combine='interleave'>
      <optional>
        <ref name='svg.XLinkHrefRequired.attr'/>
      </optional>
      <ref name='svg.XLinkShowOther.attr'/>
      <ref name='svg.XLinkActuateOnLoad.attr'/>
      <ref name='svg.XLinkBase.attr'/>
    </define>
xlink:type = "simple"

Identifies the type of XLink being used. In SVG Tiny 1.2, only simple links are available. In line with the changes proposed in XLink 1.1 [XLINK11], this attribute may be omitted on simple links. Links are simple links by default, so the attribute xlink:type="simple" is optional and need not be explicitly stated. Refer to the XML Linking Language (XLink) [XLINK10].

Animatable: no.

xlink:role = "<IRI>"

An optional IRI reference that identifies some resource that describes the intended property. The value must be an IRI reference as defined in [RFC3987], except that if the IRI scheme used is allowed to have absolute and relative forms, the IRI portion must be absolute. When no value is supplied, no particular role value shall be inferred. Refer to the XML Linking Language (XLink) [XLINK10].

Animatable: no.

xlink:arcrole = "<IRI>"

An optional IRI reference that identifies some resource that describes the intended property. The value must be an IRI reference as defined in [RFC3987], except that if the IRI scheme used is allowed to have absolute and relative forms, the IRI portion must be absolute. When no value is supplied, no particular role value shall be inferred. The arcrole attribute corresponds to the [RDF] notion of a property, where the role can be interpreted as stating that "starting-resource HAS arc-role ending-resource." This contextual role can differ from the meaning of an ending resource when taken outside the context of this particular arc. For example, a resource might generically represent a "person," but in the context of a particular arc it might have the role of "mother" and in the context of a different arc it might have the role of "daughter." Refer to the XML Linking Language (XLink) [XLINK10].

Animatable: no.

xlink:title = "<string>"

The title attribute shall be used to describe the meaning of a link or resource in a human-readable fashion, along the same lines as the role or arcrole attribute. A value is optional; if a value is supplied, it shall contain a string that describes the resource. In general it is preferable to use a 'title' child element rather than a 'title' attribute. The use of this information is highly dependent on the type of processing being done. It may be used, for example, to make titles available to applications used by visually impaired users, or to create a table of links, or to present help text that appears when a user lets a mouse pointer hover over a starting resource. Refer to the XML Linking Language (XLink) [XLINK10].

Animatable: no.

xlink:show = "new' | 'replace' | 'embed' | 'other' | 'none'

This attribute is provided for backwards compatibility with SVG 1.1. It provides documentation to XLink-aware processors. In case of a conflict, the target attribute has priority, since it can express a wider range of values. Refer to the XML Linking Language (XLink) [XLINK10].

Animatable: no.

xlink:actuate = "onLoad'

This attribute is provided for backwards compatibility with SVG 1.1. It provides documentation to XLink-aware processors. Refer to the XML Linking Language (XLink) [XLINK10].

Animatable: no.

In all cases, for compliance with either the "Namespaces in XML 1.0" or the "Namespaces in XML 1.1" Recommendation [XML-NS10][XML-NS], an explicit XLink namespace declaration must be provided whenever one of the above XLink attributes is used within SVG content. One simple way to provide such an XLink namespace declaration is to include an 'xmlns' attribute for the XLink namespace on the 'svg' element for content that uses XLink attributes.

Example: XLink namespace declaration

Example: 05_09.svg
<?xml version="1.0"?>
<svg xmlns:xlink="http://www.w3.org/1999/xlink"
  xmlns="http://www.w3.org/2000/svg" version="2.0">
  <desc>Declaring the XLink namespace, as well as the SVG one</desc>
  <image xlink:href="foo.png"/>
</svg>

Example: use and animation

The two files below are the referenced files in the 'use' and animation examples further down.

<?xml version="1.0" encoding="UTF-8"?>
<svg xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink" 
     version="2.0" 
     xml:id="animationRef" width="150" height="50" viewBox="0 0 150 50" fill="inherit">  

    <rect xml:id="aMovingRect" width="50" height="50" rx="5" ry="5" fill="inherit" stroke-width="3" stroke="black">
         <animateTransform attributeName="transform" type="translate" values="0,0;0,100" begin="0" dur="2" fill="freeze"/>
    </rect>
</svg>
<?xml version="1.0" encoding="UTF-8"?>
<svg xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink" 
     version="2.0" 
     xml:id="animationRef" width="150" height="50" viewBox="0 0 150 50" fill="inherit">  

    <rect xml:id="aMovingRect" width="50" height="50" rx="5" ry="5" fill="rgb(255,28,141)" stroke-width="3" stroke="black">
         <animateTransform attributeName="transform" type="translate" values="0,0;0,100" begin="0" dur="2" fill="freeze"/>
    </rect>
</svg>

The following example illustrates how to reference SVG content from the 'animation' element. Different 'fill' values are used to show the way properties are inherited on content referenced from the 'animation' element.

Example: animation.svg
<?xml version="1.0" encoding="UTF-8"?>
<svg xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink" 
     version="2.0" width="100%" height="100%" viewBox="0 0 580 400">  

    <g fill="rgb(157,0,79)">
        <animation x="20" xlink:href="referencedRect.svg"/>
        <animation x="100"  xlink:href="referencedRect2.svg"/>
        <animation begin="1" x="180" viewport-fill="rgb(255,28,141)" xlink:href="referencedRect.svg"/>
    </g>
    
</svg>

The image below shows the correct rendering of the animation example above. The arrows indicates the animation. The grayed rectangles shows the initial state (i.e. time=0), the colored rectangles shows the final state (animations are completed).
image showing usage of the animation element

The following example illustrates the different ways SVG content can be referenced from a 'use' element. Different 'fill' values are used to show the way properties are inherited on content referenced from the 'use' element.

Example: use.svg
<?xml version="1.0" encoding="UTF-8"?>
<svg xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink" 
     version="2.0" width="100%" height="100%" viewBox="0 0 580 400">  
    <defs>
        <g fill="green">
            <rect xml:id="aMovingRect" width="50" height="50" rx="5" ry="5" fill="inherit" stroke-width="3" stroke="black">
                <animateTransform attributeName="transform" type="translate" values="0,0;0,100" begin="0" dur="2" fill="freeze"/>
            </rect>
        </g>
    </defs>
    
    <g fill="rgb(157,0,79)">
        <use x="20" xlink:href="#aMovingRect"/>
            
        <use x="100" fill="rgb(255,28,141)" xlink:href="#aMovingRect"/>
    
        <use x="180" xlink:href="referencedRect.svg#aMovingRect"/>

        <use x="260" fill="rgb(255,28,141)" xlink:href="referencedRect.svg#aMovingRect"/>
    </g>

</svg>

The image below shows the correct rendering of the use example above. The arrows indicates the animation. The grayed rectangles shows the initial state (i.e. time=0), the colored rectangles shows the final state (animations are completed).
image showing usage of the use element

4.1.6 Processing of external references to documents

When an SVG user agent resolves an external reference to a document, how the document is loaded and processed depends on how the document was referenced. As defined below, a document is classified as either a primary document or a resource document, and this classification determines the document's processing with respect to loading of external references.

A primary document is one that is to be presented in whole by the user agent. Specifically, the following are classified as primary documents:

A resource document is a document that has been loaded because parts of it are referenced as resources by an SVG document fragment. Specifically, the following kinds of external references, all of which are references to elements, will cause the loaded document to be classified as a resource document:

Note that neither a primary document nor a resource document need be a complete SVG document (with the rootmost 'svg' element being the document element). Both may be non-SVG documents that contain SVG document fragments.

Each primary document maintains a dictionary that maps IRIs to resource documents. This dictionary is used whenever a resource document is to be loaded because an SVG document fragment within the primary document (or one of its resource documents) references it. Before loading a resource document, its IRI is first looked up in the primary document's dictionary to determine if it has already been loaded. If so, then that already-loaded document is used instead of creating a separate document instance. Thus, for each primary document, a given resource document is loaded only once. Primary documents, however, are always separate, self-contained document instances, and resource documents are not shared between different primary documents.

The IRI used as the key in the dictionary of resource documents must be the absolute IRI after resolving it against any applicable base IRI, and comparisons of the dictionary keys must be performed using a Simple String Comparison, as defined in section 5.3.1 of Internationalized Resource Identifiers [RFC3987].

Whether a document is a primary document or a resource document, its processing once loaded is the same: each SVG document fragment within the document acts as a separate SVG processing context in which events are fired, scripts are executed, an animation timeline is created and animations are run, stylesheets are applied (if supported by the SVG user agent), and so on. Since a resource document is not just a static DOM, any changes to it (be they modifications by script or changing presentation values with animation) will be visible through all references to that resource document.

Note that since IRI references to resources from different primary documents will result in logically separate resource documents being instantiated, an SVG user agent will in general not be able to conserve memory by having only one instance of the resource document in memory. In the case that many primary documents all have references to a single, large, common resource file, this will likely result in a large amount of memory consumed. If the SVG user agent is able to prove that the primary documents will behave exactly the same if a single instance is shared in memory (by using copy-on-write semantics for the resource documents, for example), then such an optimization may of course be performed.

References to any other kinds of document, such as media or external scripts, are not classified as primary or resource documents. Multiple references to media at a particular IRI always result in separate timelines being created.

4.2 Links out of SVG content: the 'a' element

SVG provides an 'a' element, analogous to HTML's 'a' element, to indicate links (also known as hyperlinks or Web links). SVG uses XLink [XLINK10] for all link definitions.

SVG Tiny 1.2 only requires that user agents support XLink's notion of simple links. Each simple link associates exactly two resources, one local and one remote, with an arc going from the former to the latter.

A simple link is defined for each separate rendered element contained within the 'a' element; thus, if the 'a' element contains three 'circle' elements, a link is created for each circle. For each rendered element within an 'a' element, the given rendered element is the local resource (the source anchor for the link).

The remote resource (the destination for the link) is defined by an IRI specified by the XLink 'href' attribute on the 'a' element. The remote resource may be any Web resource (e.g., an image, a video clip, a sound bite, a program, another SVG document, an HTML document, etc.). By activating these links (by clicking with the mouse, through keyboard input, voice commands, etc.), users may traverse hyperlinks to these resources.

If the IRI identifies an animation element within the current SVG document fragment, then activating the 'a' element will hyperlink to the animation, as defined in SMIL 2.1 ([SMIL21], section 10.4.3).

Example 17_01 assigns a link to an ellipse.

Example: 17_01.svg
<?xml version="1.0"?>
<svg width="5cm" height="3cm" viewBox="0 0 5 3" version="2.0"
     xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink">

  <title>Example 17_01</title>
  <desc>A simple link on an ellipse.</desc>
  <rect x=".01" y=".01" width="4.98" height="2.98" 
        fill="none" stroke="blue"  stroke-width=".03"/>
  <a xlink:href="http://www.w3.org/">
    <ellipse cx="2.5" cy="1.5" rx="2" ry="1"
             fill="red" />
  </a>
</svg>
Rendering of 17_01.svg

If the above SVG file is viewed by a user agent that supports both SVG and HTML, then clicking on the ellipse will cause the current window or frame to be replaced by the W3C home page.

The element definition schema and content model for 'a' is not defined here. It is defined in all the places it can occur.

Schema: a.at
    <define name='a.AT' combine='interleave'>
      <ref name='svg.Core.attr'/>
      <ref name='svg.Conditional.attr'/>
      <ref name='svg.Properties.attr'/>
      <ref name='svg.FocusHighlight.attr'/>
      <ref name='svg.External.attr'/>
      <ref name='svg.Focus.attr'/>
      <ref name='svg.Transform.attr'/>
      <ref name='svg.XLinkReplace.attr'/>
      <optional>
        <attribute name='target' svg:animatable='true' svg:inheritable='false'>
          <choice>
            <value>_replace</value>
            <value>_self</value>
            <value>_parent</value>
            <value>_top</value>
            <value>_blank</value>
            <ref name='XML-Name.datatype'/>
          </choice>
        </attribute>
      </optional>
    </define>

Attribute definitions:

xlink:type = "simple"

See generic description of 'xlink:type' attribute.

xlink:role = "<IRI>"

See generic description of 'xlink:role' attribute.

xlink:arcrole = "<IRI>"

See generic description of 'xlink:arcrole' attribute.

xlink:title = "<string>"

See generic description of 'xlink:title' attribute.

xlink:show = "new" | "replace"

This attribute is provided for backwards compatibility with SVG 1.1. It provides documentation to XLink-aware processors. If target="_blank" then use xlink:show="new" else use 'replace'. In case of a conflict, the target attribute has priority, since it can express a wider range of values. Refer to the XML Linking Language (XLink) [XLINK10].

Animatable: no.

xlink:actuate = "onRequest"

This attribute is provided for backwards compatibility with SVG 1.1. It provides documentation to XLink-aware processors that an application should traverse from the starting resource to the ending resource only on a post-loading event triggered for the purpose of traversal. Refer to the XML Linking Language (XLink) [XLINK10].

Animatable: no.

xlink:href = "<IRI>"

The location of the referenced object, expressed as an IRI reference.

Animatable: yes.

target = "_replace" | "_self" | "_parent" | "_top" | "_blank" | "<XML-Name>"

This attribute should be used when there are multiple possible targets for the ending resource, such as when the parent document is a multi-frame HTML or XHTML document. This attribute specifies the name or portion of the target window, frame, pane, tab, or other relevant presentation context (e.g., an HTML or XHTML frame, iframe, or object element) into which a document is to be opened when the link is activated. The values and semantics of this attribute are the same as the WebCGM Picture Behavior values [WEBCGM]:

_replace
The current SVG image is replaced by the linked content in the same rectangular area in the same frame as the current SVG image.
_self
The current SVG image is replaced by the linked content in the same frame as the current SVG image. This is the lacuna value, if the target attribute is not specified.
_parent
The immediate frameset parent of the SVG image is replaced by the linked content.
_top
The content of the full window or tab, including any frames, is replaced by the linked content
_blank
A new un-named window or tab is requested for the display of the linked content. If this fails, the result is the same as _top
<XML-Name>
Specifies the name of the frame, pane, or other relevant presentation context for display of the linked content. If this already exists, it is re-used, replacing the existing content. If it does not exist, it is created (the same as '_blank', except that it now has a name).

Note: The value '_new' is not a legal value for target (use '_blank').

Animatable: yes.

focusable = "true" | "false" | "auto"

See attribute definition for description.

Animatable: yes.

Navigation Attributes

See definition.

Typically, HTML user agents, by convention, style the content of anchor elements to indicate that they are links, for example by underlining and changing the color of text and creating a colored border around images and other replacement content. Because SVG is a visual language with irregular shapes and complex link structure (e.g. allowing links within other links), and is intended to allow more precise control over the appearance of the content, SVG user agents should not provide default styling to child content of an 'a' element, instead allowing authors to control the linking conventions.

However, in order to ensure that links are obvious to users and to provide detailed information about each link, SVG user agents should provide a clear indicator when a link is in scope. A link shall be considered to be in scope if one of the child elements of that 'a' element has a pointer device cursor hovered over it or when that element is the currently focused element. The user agent should change the scope indicator to signal that a link is in scope (e.g. the cursor may be changed to a pointing hand, or the focus highlight may be color-coded to indicate the status of the link), should indicate the URI of the link (by displaying it in a status bar, or reading it aloud, for example), and should display any author-supplied information about the link (as with a tooltip). Authors should use the 'xlink:title' attribute appropriately on links, in order to provide information about the link to users.

4.3 Linking into SVG content: IRI fragments and SVG views

4.3.1 Introduction: IRI fragments and SVG views

Because SVG content often represents a picture or drawing of something, a common need is to link into a particular view of the document, where a view indicates the initial transformations so as to present a closeup of a particular section of the document.

4.3.2 SVG fragment identifiers

To link into a particular view of an SVG document, the IRI fragment identifier must be a correctly formed SVG fragment identifier. An SVG fragment identifier defines the meaning of the "selector" or "fragment identifier" portion of IRIs that locate resources of MIME media type "image/svg+xml".

An SVG fragment identifier can come in two forms:

  1. Shorthand bare name form of addressing (e.g., someDrawing.svg#someView). This form of addressing, which allows addressing an SVG element by its ID, is compatible with the fragment addressing mechanism for older versions of HTML and the shorthand bare name formulation in XPointer Framework [XPTRFW].
  2. SVG view specification (e.g., someDrawing.svg#svgView(transform(scale(2))). This form of addressing specifies the desired view of the document (e.g., the region of the document to view, the initial zoom level) completely within the SVG fragment specification. The contents of the SVG view specification is "transform(...)" whose parameters have the same meaning that the corresponding attribute has on a 'g' element has).

An SVG fragment identifier is defined as follows:

SVGFragmentIdentifier ::= BareName |
                          SVGViewSpec

BareName ::= NCName
SVGViewSpec ::= 'svgView(' SVGViewAttributes ')'
SVGViewAttributes ::= SVGViewAttribute |
                      SVGViewAttribute ';' SVGViewAttributes

SVGViewAttribute ::= transformSpec
transformSpec ::= 'transform(' TransformList ')'

where:

An SVG fragment identifier must match the specified grammar. To ensure robust content, authors are recommended to omit spaces between numeric values, or replace these spaces with percent-encoded strings or commas as appropriate.

Note: since fragment identifiers are stripped from IRIs before resolution, there is no need to escape any characters in fragments that are outside the repertoire of US-ASCII.

When a user agent traverses a link to an SVG document fragment, whether from within the same document or from an external source document, then the SVG fragment identifier shall specify the initial view into the SVG document. This applies whether the link is from an SVG 'a' element, an HTML anchor element [HTML4] (i.e., an <a href=...> element in HTML), or any specification using XLink [XLINK10]. The user agent shall take the following steps in determining the effect of the link traversal:

Note: In SVG Tiny 1.2, only a single 'svg' element is allowed. Thus, the closest ancestor 'svg' element and the rootmost 'svg' element are the same. This is not true in other profiles of SVG, where the distinction becomes significant.


4 Metadata

Contents

4.1 Introduction

Metadata is structured data about data.

In the computing industry, there are ongoing standardization efforts towards metadata with the goal of promoting industry interoperability and efficiency. Content creators should track these developments and include appropriate metadata in their SVG content which conforms to these various metadata standards as they emerge.

The W3C has a Semantic Web Activity which has been established to serve a leadership role, in both the design of enabling specifications and the open, collaborative development of technologies that support the automation, integration and reuse of data across various applications. The Semantic Web Activity builds upon the earlier W3C Metadata Activity, including the definition of RDF (Resource Description Framework). The set of six specifications for RDF can be found starting with the Resource Description Framework Primer [RDF]

Another activity relevant to most applications of metadata is the Dublin Core [DCORE], which is a set of generally applicable core metadata properties (e.g., Title, Creator/Author, Subject, Description, etc.).

A popular usage of RDF metadata in the SVG community is the inclusion of license terms using the Creative Commons [CC] license framework. The popular open-source SVG authoring tool Inkscape can automatically include this license information, and inclusion of such a license is required by many collaborative Web sites. This indicates the potential and impact of metadata.

Individual industries or individual content creators are free to define their own metadata schema but are encouraged to follow existing metadata standards and use standard metadata schema wherever possible to promote interchange and interoperability. If a particular standard metadata schema does not meet your needs, then it is usually better to define an additional metadata schema in an existing framework such as RDF and to use custom metadata schema in combination with standard metadata schema, rather than totally ignore the standard schema.

SVG provides two mechanisms for adding metadata directly to a document: the 'metadata' element, and several metadata attributes. These different mechanisms may be used independently, or in concert. If both are being used for RDF (that is, RDF and RDFa), then an RDF processor should combine them into the same graph. (Note: metadata attributes should not be used directly on RDF elements.)

4.2 The 'metadata' element

Metadata which is included with SVG content should be specified within 'metadata' elements. The contents of the 'metadata' should be elements from other XML namespaces, with these elements from these namespaces expressed in a manner conforming with either the Namespaces in XML 1.0 or Namespaces in XML 1.1 Recommendations [XML-NS10][XML-NS].

Authors should provide a 'metadata' child element to the 'svg' element within a stand-alone SVG document. The 'metadata' child element to an 'svg' element serves the purposes of identifying document-level metadata.

If a 'metadata' element is placed as a child of a non-root element with the intent to apply directly to that element, it is recommended that the author indicate this explicitly in the content of the 'metadata' element, if that content provides a way to do so. For example, when using RDF, the target element should be given an 'id' attribute, and the 'about' attribute of the RDF should reference that 'id'.

4.2.1 A 'metadata' element example

Here is an example of how metadata can be included in an SVG document. The example uses the Creative Commons schema to indicate the usage license of a work of art. (Other XML-compatible metadata languages, including ones not based on RDF, can be used also.)

4.3 Extensible metadata attributes

In addition to the 'metadata' element, which allows for the direct inclusion of metadata document fragments from other namespaces, SVG includes several attributes that may be placed on any element, for the use of attribute-based metadata formats. These include the 'class', 'role', 'rel', 'rev', 'about', 'content', 'datatype', 'property', 'resource', and 'typeof' attributes. SVG makes no specific requirements about the values for these attributes, other than their particular value data types, such as a string or a space-separated lists of strings. Other specifications, such as RDFa [RDFA], Microformats patterns [MF], or ARIA ontologies [ARIA], may impose stricter requirements in order to conform to that particular language, which should be expressed as an additional schema for purposes of validation. A few informative examples of such restrictions include:

SVG does not mandate or require support for any of these languages, formats, or ontologies, but it includes these metadata attributes to enable their use as the author desires. Note that this specification's description of these complementary formats is intended for illustrative purposes only, and does not impose additional restrictions on those formats.

In order to maintain consistency and simplicity of implementation, and prevent conflict or ambiguity of use, if an author or a non-RDFa format reuses the 'about', 'content', 'datatype', 'property', 'resource', or 'typeof' attributes, it is recommended that this is done in a manner consistent with the RDFa Syntax Processing Rules [RDFA].

Currently, many SVG documents contain RDF metadata that provides a title in the Dublin Core [DCORE] namespace, which is useful for certain types of processing, but which is not treated as a title for the document by many user agents. It is recommended that authoring tools which embed RDF metadata that contains a title also provide at least a document-level 'title' element. The following example shows how the 'property' attribute may be combined with the descriptive elements to supply both a human- and machine-readable title, in the manner of RDFa.