This specification defines the features and syntax for Scalable Vector Graphics (SVG) Tiny, Version 1.2, 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 1.2 Tiny 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 1.2 Tiny, 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 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, but is named SVG Tiny for historical reasons, as a profile for mobile devices. Future versions of this specification will maintain backwards compatibility with previous versions of the language, in a continuing line of technology, but will bear the name "SVG Core" to represent this relationship.

Please send questions or comments regarding the SVG 1.2 Tiny 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.

Authors

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

Acknowledgments

The SVG Working Group would like to acknowledge 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.

1 Introduction

1.1 About SVG
1.2 SVG Tiny 1.2
- 1.2.1 Profiling the SVG specification
1.3 Defining an SVG Tiny 1.2 document
1.4 SVG MIME type, file name extension and Macintosh file type
1.5 Compatibility with other standards efforts
1.6 Definitions
1.7 How to reference this specification
1.8 How to use this specification

1.1 About SVG

SVG is a language for describing two-dimensional graphics in XML [XML10, XML11]. 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 declaratively (i.e., by embedding SVG animation elements in SVG content) or via scripting.

Sophisticated applications of SVG are possible by use of a supplemental scripting language which accesses the SVG Micro Document Object Model (uDOM), which provides complete access to all elements, attributes and properties. 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 XHTML 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.

It is believed that this specification is in accordance with the Web Architecture principles as described in Architecture of the World Wide Web [AWWW].

1.2 SVG Tiny 1.2

Industry demand, overwhelming support in the SVG working group and requests from the SVG developer community established the need for some form of SVG suited to displaying vector graphics on small devices. Moreover, the mission statement of SVG 1.0 specifically addressed small devices as a target area for vector graphics display. In order to meet these demands the SVG Working Group created a profile specification that was suitable for use on mobile devices as well as on desktops. The Mobile SVG Profiles specification [SVGM11] (also known as SVG Mobile 1.1) addressed that requirement and defined two profiles to deal with the variety of mobile devices having different characteristics in terms of CPU speed, memory size, and color support. The SVG Mobile 1.1 specification defined SVG Tiny (SVGT) 1.1, suitable for highly restricted mobile devices; it also defined a second profile, SVG Basic (SVGB) 1.1, targeted for higher level mobile devices. The major difference between SVG Tiny 1.1 and SVG Basic 1.1 was the absence of scripting and styling in SVG 1.1 Tiny, and thus any requirement to maintain a Document Object Model (DOM). This saved a substantial amount of memory in most implementations.

Experience with SVG Tiny 1.1, which was widely adopted in the industry and shipped as standard on a variety of cellphones, indicated that the profile was a little too restrictive in some areas. Features from SVG 1.1 such as gradients and opacity were seen to have substantial value for creating attractive content, and were shown to be implementable on cellphones. There was also considerable interest in adding audio and video capabilities, building on the SMIL support in SVG Tiny 1.1.

Advances such as DOM Level 3, which introduces namespace support and value normalization, prompted a second look at the use of programming languages and scripting with SVG Tiny. In conjunction with the Java JSR 226 group [JSR226], a lightweight interface called the Micro DOM, or uDOM, was developed. This could be, but need not be, implemented on top of DOM Level 3. With this advance, lightweight programmatic control of SVG (for example, for games or user interfaces) and use with scripting languages, became feasible on the whole range of platforms from cellphones through to desktops. In consequence, there is only a single Mobile profile for SVG 1.2: SVG Tiny 1.2.

This specification defines the features and syntax for Scalable Vector Graphics (SVG) Tiny 1.2, the core specification and baseline profile of SVG 1.2. Other SVG specifications will extend this baseline functionality to create supersets (for example, SVG 1.2 Full). The SVG Tiny 1.2 specification adds to SVG Tiny 1.1 features requested by SVG authors, implementors and users; SVG Tiny 1.2 is a superset of SVG Tiny 1.1.

1.2.1 Profiling the SVG specification

The Tiny profile of SVG 1.2 consists of all of the features defined within this specification. As a baseline specification, it is possible for: superset profiles (e.g., SVG Full 1.2) which include all of the Tiny profile but add other features to the baseline; subset profiles; and special-purpose profiles which incorporate some modules from this specification in combination with other features as needed to meet particular industry requirements.

When applied to conformance, the term "SVG Tiny 1.2" refers to the Tiny profile of SVG 1.2 defined by this specification. If an implementation does not implement the Tiny profile completely, the UA's conformance claims must state either the profile to which it conforms and/or the specific set of features it implements.

1.3 Defining an SVG Tiny 1.2 document

SVG Tiny 1.2 is a backwards compatible upgrade to SVG Tiny 1.1 [SVGM11]. Backwards compatible means that conformant SVG Tiny 1.1 content will render the same in conformant SVG Tiny 1.2 user agents as it did in conformant SVG Tiny 1.1 user agents. A few key differences from SVG Tiny 1.1 should be noted:

The value of the 'version' attribute on the rootmost 'svg' element should be '1.2'. See the description of version control in the Implementation Requirements appendix for details.
There is no DTD for SVG 1.2, and therefore no need to specify the DOCTYPE for an SVG 1.2 document (unless it is desired to use the internal DTD subset ([XML10], section 2.8, and [XML11], section 2.8), for purposes of entity definitions for example). Instead, identification is by the SVG namespace, plus the 'version' and 'baseProfile' attributes. In SVG Tiny 1.2, validation can be performed using the RelaxNG schema.

The namespace for SVG Tiny 1.2 is the same as that of SVG 1.0 and 1.1, 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 Tiny 1.2 document:

Example: 01_01.svg

<?xml version="1.0"?>
<svg xmlns="http://www.w3.org/2000/svg" version="1.2" baseProfile="tiny"
     viewBox="0 0 30 30">
  <desc>Example SVG file</desc>
  <rect x="10" y="10" width="10" height="10" fill="red"/>
</svg>

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 Tiny 1.2 but instead provides a normative RelaxNG schema.

Example: entity.svg

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE svg [
    <!ENTITY Smile "
    <rect x='.5' y='.5' width='29' height='39' fill='black' stroke='red'/>
    <g transform='translate(0, 5)'>
    <circle cx='15' cy='15' r='10' fill='yellow'/>
    <circle cx='12' cy='12' r='1.5' fill='black'/>
    <circle cx='17' cy='12' r='1.5' fill='black'/>
    <path d='M 10 19 L 15 23 20 19' stroke='black' stroke-width='2'/>
    </g>
    ">
    ]>
<svg xmlns="http://www.w3.org/2000/svg" version="1.2" baseProfile="tiny">
  <title>Smiley face</title>
  <desc>
    This example shows the use of an entity defined in the
    internal DTD subset. Note that there is no external DTD subset
    for SVG Tiny 1.2, and thus no formal public identifier.
  </desc>
  &Smile; 
</svg>

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 Tiny 1.2 leverages and integrates with other W3C specifications and standards efforts. By leveraging and conforming to other standards, SVG becomes more powerful and makes it easier for users to learn how to incorporate SVG into their Web sites.

The following describes some of the ways in which SVG maintains compatibility with, leverages and integrates with other W3C efforts:

SVG Tiny 1.2 is an application of XML and is compatible with both the Extensible Markup Language (XML) 1.1 [XML11] and Extensible Markup Language (XML) 1.0 (Third Edition) [XML10] Recommendations.
SVG Tiny 1.2 is compatible with both the Namespaces in XML 1.0 [XML-NS10] and the Namespaces in XML 1.1 [XML-NS] Recommendations.
SVG Tiny 1.2 utilizes XML Linking Language (XLink) [XLINK10] for IRI referencing and requires support for base IRI specifications defined in XML Base [XML-BASE].
SVG Tiny 1.2 uses the 'xml:id' attribute as defined in xml:id Version 1.0 [XMLID].
SVG Tiny 1.2 content can be generated using XSL Transformations (XSLT) Version 1.0 [XSLT] or Version 2.0 [XSLT2]. (See Styling with XSL.)
SVG Tiny 1.2 supports formatting properties drawn from CSS and XSL. (See SVG's styling properties).
SVG Tiny 1.2 includes a compatible subset of the Document Object Model (DOM) and supports many of the facilities described in Document Object Model (DOM) Level 3 Core [DOM3], including namespace support and event handling.
SVG Tiny 1.2 incorporates some features from the Synchronized Multimedia Integration Language (SMIL) 2.1 Specification [SMIL21], including the 'prefetch' and 'switch' elements, the 'systemLanguage' attribute, animation features (see Animation) and the ability to reference audio and video media (see Multimedia). SVG's animation features incorporate and extend the general-purpose XML animation capabilities described in SMIL 2.1. In addition, SVG Tiny 1.2 has been designed to allow SMIL 2.1 to use animated or static SVG content as media components.
SVG is compatible with W3C work on internationalization. References (W3C and otherwise) include: The Unicode Standard [UNICODE] and the Character Model for the World Wide Web 1.0 [CHARMOD]. (See Internationalization Support.)
SVG is compatible with W3C work on Web Accessibility [WAI]. (See Accessibility Support).

In environments which support the Document Object Model (DOM) Core [DOM3] for other XML grammars (e.g., XHTML 1.0 [XHTML]) and which also support SVG and the SVG DOM, a single scripting approach can be used simultaneously for both XML documents and SVG graphics, in which case interactive and dynamic effects will be possible on multiple XML namespaces using the same set of scripts.

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.11.2 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 Tiny 1.2 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 Tiny 1.2 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):

a 'defs', 'discard', 'font', 'handler', 'linearGradient', 'listener', 'metadata', 'mpath', 'prefetch', 'radialGradient', 'script' or 'solidColor' element
elements whose 'display' property is set to 'none'
elements with one or more conditional processing attributes that evaluate to false
direct children of a 'switch' element, other than the child that evaluates to true
animation elements

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 Tiny 1.2 (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 1.2 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 Tiny 1.2, 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 Tiny 1.2, 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 Tiny 1.2, 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 Tiny 1.2 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 Tiny 1.2 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/SVGTiny12/, 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 Micro DOM (uDOM).

5 Document Structure

5.1 Defining an SVG document fragment: the 'svg' element
- 5.1.1 Overview
- 5.1.2 The 'svg' element
5.2 Grouping: the 'g' element
- 5.2.1 Overview
- 5.2.2 The 'g' element
5.3 The 'defs' element
5.4 The 'discard' element
5.5 The 'title' and 'desc' elements
- 5.5.1 Applicable 'title' and 'desc'
- 5.5.2 Multiple 'title' and 'desc' elements
- 5.5.3 User interface behavior for 'title' and 'desc'
5.6 The 'use' element
5.7 The 'image' element
5.8 Conditional processing
- 5.8.1 Conditional processing overview
- 5.8.2 The 'switch' element
- 5.8.3 The 'requiredFeatures' attribute
- 5.8.4 The 'requiredExtensions' attribute
- 5.8.5 The 'systemLanguage' attribute
- 5.8.6 The 'requiredFormats' attribute
- 5.8.7 The 'requiredFonts' attribute
5.9 External resources
- 5.9.1 The 'externalResourcesRequired' attribute
- 5.9.2 Progressive rendering
- 5.9.3 The 'prefetch' element
5.10 Common attributes
- 5.10.1 Attributes common to all elements
- 5.10.2 Attributes for character-content elements

5.1 Defining an SVG document fragment: the 'svg' element

5.1.1 Overview

An SVG document fragment consists of any number of SVG elements contained within an 'svg' element, including the 'svg' element.

An SVG document fragment can range from an empty fragment (i.e., no content inside of the 'svg' element), to a very simple SVG document fragment containing a single SVG graphics element such as a 'rect', to a complex, deeply nested collection of container elements and graphics elements.

An SVG document fragment can stand by itself as a self-contained file or resource, in which case the SVG document fragment is an SVG document, or it can be embedded inline as a fragment within a parent XML document.

The following example shows simple SVG content embedded inline as a fragment within a parent XML document. Note the use of XML namespaces to indicate that the 'svg' and 'ellipse' elements belong to the SVG namespace:

Example: 05_01.xml

<?xml version="1.0"?>
<parent xmlns="http://example.org"
        xmlns:svg="http://www.w3.org/2000/svg">
   <!-- parent contents here -->
   <svg:svg width="4cm" height="8cm" version="1.2" baseProfile="tiny" viewBox="0 0 100 100">
      <svg:ellipse cx="50" cy="50" rx="40" ry="20" />
   </svg:svg>
   <!-- ... -->
</parent>

This example shows a slightly more complex (i.e., it contains multiple rectangles) stand-alone, self-contained SVG document:

Example: 05_02.svg

<?xml version="1.0" encoding="UTF-8"?>
<svg xmlns="http://www.w3.org/2000/svg" version="1.2" baseProfile="tiny"
     width="5cm" height="4cm" viewBox="0 0 100 100">

  <desc>Four separate rectangles</desc>

  <rect x="20" y="20" width="20" height="20"/>
  <rect x="50" y="20" width="30" height="15"/>
  <rect x="20" y="50" width="20" height="20"/>
  <rect x="50" y="50" width="20" height="40"/>

  <!-- Show outline of canvas using 'rect' element -->
  <rect x="1" y="1" width="98" height="98"
        fill="none" stroke="blue" stroke-width="2" />
</svg>

An SVG document fragment can only contain one single 'svg' element, this means that 'svg' elements cannot appear in the middle of SVG content.

In all cases, for compliance with either the Namespaces in XML 1.0 or Namespaces in XML 1.1 Recommendations [XML-NS10, XML-NS], an SVG namespace declaration must be in scope for the 'svg' element, so that all SVG elements are identified as belonging to the SVG namespace.

For example, an 'xmlns' attribute without a prefix could be specified on an 'svg' element, which means that SVG is the default namespace for all elements within the scope of the element with the 'xmlns' attribute:

Example: 05_03.svg

<?xml version="1.0"?>
<svg xmlns="http://www.w3.org/2000/svg" version="1.2" baseProfile="tiny">
  <desc>Demonstrates use of a default namespace prefix for elements.</desc>
  <rect width="7" height="3"/>
</svg>

If a namespace prefix is specified on the 'xmlns' attribute (e.g., xmlns:svg="http://www.w3.org/2000/svg"), then the corresponding namespace is not the default namespace, so an explicit namespace prefix must be assigned to the elements:

Example: 05_04.svg

<?xml version="1.0"?>
<s:svg xmlns:s="http://www.w3.org/2000/svg" version="1.2" baseProfile="tiny">
  <s:desc>Demonstrates use of a namespace prefix for elements.
    Notice that attributes are not namespaced</s:desc>
  <s:rect width="7" height="3"/>
</s:svg>

Namespace declarations can also be specified on ancestor elements (illustrated in example 05_01, above). For more information, refer to the Namespaces in XML 1.0 or Namespaces in XML 1.1 Recommendations [XML-NS10, XML-NS].

5.1.2 The 'svg' element

Schema: svg

    <define name='svg'>
      <element name='svg'>
        <ref name='svg.AT'/>
        <zeroOrMore><ref name='svg.G.group'/></zeroOrMore>
      </element>
    </define>

    <define name='svg.AT' combine='interleave'>
      <ref name='svg.Properties.attr'/>
      <ref name='svg.FocusHighlight.attr'/>
      <ref name='svg.External.attr'/>
      <ref name='svg.Focus.attr'/>
      <ref name='svg.AnimateSyncDefault.attr'/>
      <ref name='svg.Core.attr'/>
      <ref name='svg.WH.attr'/>
      <ref name='svg.PAR.attr'/>
      <optional>
        <attribute name='viewBox' svg:animatable='true' svg:inheritable='false'>
          <text/>
        </attribute>
      </optional>
      <optional>
        <attribute name='zoomAndPan' svg:animatable='false' svg:inheritable='false'>
          <choice>
            <value>disable</value>
            <value>magnify</value>
          </choice>
        </attribute>
      </optional>
      <optional>
        <attribute name='version' svg:animatable='false' svg:inheritable='false'>
          <choice>
            <value type='string'>1.0</value>
            <value type='string'>1.1</value>
            <value type='string'>1.2</value>
          </choice>
        </attribute>
      </optional>
      <optional>
        <attribute name='baseProfile' svg:animatable='false' svg:inheritable='false'>
          <choice>
            <value type='string'>none</value>
            <value type='string'>tiny</value>
            <value type='string'>basic</value>
            <value type='string'>full</value>
          </choice>
        </attribute>
      </optional>
      <optional>
        <attribute name='contentScriptType' svg:animatable='false' svg:inheritable='false'>
          <ref name='ContentType.datatype'/>
        </attribute>
      </optional>
      <optional>
        <attribute name='snapshotTime' svg:animatable='false' svg:inheritable='false'>
          <choice>
            <value type='string'>none</value>
            <ref name='Clock-value.datatype'/>
          </choice>
        </attribute>
      </optional>
      <optional>
        <attribute name='timelineBegin' svg:animatable='false' svg:inheritable='false'>
          <choice>
            <value type='string'>onLoad</value>
            <value type='string'>onStart</value>
          </choice>
        </attribute>
      </optional>
      <optional>
        <attribute name='playbackOrder' svg:animatable='false' svg:inheritable='false'>
          <choice>
            <value type='string'>all</value>
            <value type='string'>forwardOnly</value>
          </choice>
        </attribute>
      </optional>
    </define>

Attribute definitions:

version = "1.0" | "1.1" | "1.2"

Indicates the SVG language version to which this document fragment conforms.

In SVG 1.0 and SVG 1.1 this attribute had the value '1.0' or '1.1' respectively, and SVG 1.2 adds the value '1.2'. See rules for version processing for further instructions, notably on handling of unsupported values.

Modifying the 'version' attribute using the DOM does not cause any change in behavior. In this case, the original value of the attribute is the one used for document processing.

Animatable: no.

baseProfile = "none" | "full" | "basic" | "tiny"

Describes the minimum SVG language profile that the author believes is necessary to correctly render the content. See rules for baseProfile processing for further instructions.

This specification defines the values 'none' and 'tiny'. The value 'full' corresponds to all features in the SVG language; for SVG 1.1, this corresponds to the language features defined in the SVG 1.1 Specification [SVG11]. The value 'basic' was defined in the Mobile SVG Profiles: SVG Tiny and SVG Basic [SVGM11]. This specification corresponds to baseProfile="tiny" and version="1.2". A value of 'none' provides no information about the minimum language profile that is necessary to render the content.

The lacuna value is 'none'.

Modifying the 'baseProfile' attribute using the DOM does not cause any change in behavior. In this case, the original value of the attribute is the one used for document processing.

Animatable: no.

width = "<length>"

The intrinsic width of the SVG document fragment. Together with the 'height', 'viewBox' and 'preserveAspectRatio' attributes it defines the intrinsic aspect ratio and (unless both width and height are percentages) the intrinsic size of the svg element. See The initial viewport.

A negative value is unsupported. A value of zero disables rendering of the element.

The lacuna value is '100%'.

Animatable: yes.

height = "<length>"

The intrinsic height of the SVG document fragment.

A negative value is unsupported. A value of zero disables rendering of the element.

The lacuna value is '100%'.

Animatable: yes.

viewBox = "<list-of-numbers>" | "none"

See attribute definition for description.

Animatable: yes.

preserveAspectRatio = "[defer] <align> [<meet>]"

See attribute definition for description.

Animatable: yes.

snapshotTime = "<clock-value>" | "none"

Indicates a moment in time which is most relevant for a still-image of the animated SVG content. This time may be used as a hint to the SVG user agent for rendering a still-image of an animated SVG document, such as a preview. A value of 'none' means that no 'snapshotTime' is available. See example 05_22 for an example of using the 'snapshotTime' attribute.

The lacuna value is 'none'.

Animatable: no.

playbackOrder = "forwardOnly" | "all"

Indicates whether it is possible to seek backwards in the document. In earlier versions of SVG there was no need to put restrictions on the direction of seeking but with the newly introduced facilities for long-running documents (e.g. the 'discard' element) there is sometimes a need to restrict this.

If 'playbackOrder' is set to 'forwardOnly', the content will probably contain 'discard' elements or scripts that destroy resources, thus seeking back in the document's timeline may result in missing content. If 'playbackOrder' is 'forwardOnly', the content should not provide a way, through hyperlinking or script, of seeking backwards in the timeline. Similarly the UA should disable any controls it may provide in the user interface for seeking backwards. Content with 'playbackOrder' = 'forwardOnly' that provides a mechanism for seeking backwards in time may result in undefined behavior or a document that is in error.

'forwardOnly': This file is intended to be played only in the forward direction, sequentially, therefore seeking backwards should not be allowed.
'all': Indicates that the document is authored appropriately for seeking in both directions.

The lacuna value is 'all'.

Animatable: no.

timelineBegin = "onLoad" | "onStart"

Controls the initialization of the timeline for the document.

The 'svg' element controls the document timeline, which is the timeline of the 'svg' element's time container. For progressively loaded animations, the author would typically set this attribute to 'onStart', thus allowing the timeline to begin as the document loads, rather than waiting until the complete document is loaded.

'onLoad': The document's timeline starts the moment the load event for the rootmost 'svg' element is triggered.
'onStart': The document's timeline starts at the moment the rootmost 'svg' element's start-tag (as defined in XML 1.0 ([XML10], section 3.1), or XML 1.1 ([XML11], section 3.1), if the document is an XML 1.1 document) is fully parsed and processed.

The lacuna value is 'onLoad'.

Animatable: no.

contentScriptType = "<content-type>"

Identifies the default scripting language for the given document. This attribute sets the default scripting language for all the instances of script in the document fragment. This language must be used for all scripts that do not specify their own scripting language. The <content-type> value specifies a media type, per Multipart Internet Mail Extensions: (MIME) Part Two: Media Types [RFC2046]. The lacuna value is "application/ecmascript".

Animatable: no.

zoomAndPan = "magnify" | "disable"

See attribute definition for description.

Animatable: no.

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

See attribute definition for description.

Animatable: yes.

Navigation Attributes

See definition.

Note that 'animateMotion' and 'animateTransform' are legal as children to 'svg' but don't apply to their 'svg' parent (since the 'svg' element doesn't have a 'transform' attribute). They only have any effect if the 'xlink:href' attribute is specified so that they target a different element for animation.

Content produced by illustration programs originally targeted at print often has a fixed width and height, which will prevent it scaling for different display resolutions. The first example below has a fixed width and height in pixels, and no 'viewBox'.

Example: width-height.svg

<?xml version="1.0"?>
<svg xmlns="http://www.w3.org/2000/svg" version="1.2" baseProfile="tiny"
     width="300px" height="600px">
  <desc>...</desc>
</svg>

Normally, SVG content is designed to be scalable. In order for the SVG content to scale automatically to fill the available viewport, it must include a 'viewBox' attribute on the 'svg' element. This describes the region of world coordinate space (the initial user coordinate system) used by the graphic. This attribute thus provides a convenient way to design SVG documents to scale-to-fit into an arbitrary viewport.

The second example is scalable, using a 'viewBox' rather than a fixed width and height.

Example: viewBox.svg

<?xml version="1.0"?>
<svg xmlns="http://www.w3.org/2000/svg" version="1.2" 
     baseProfile="tiny" viewBox="0 0 300 600">
  <desc>...</desc>
</svg>

Below is an example of 'snapshotTime'. An SVG user agent is displaying a number of SVG files in a directory by rendering a thumbnail image. It uses the 'snapshotTime' as the time to render when generating the image, thus giving a more representative static view of the animation. The appearance of the thumbnail for an SVG user agent that honors the 'snapshotTime' and for an SVG user agent that does not is shown below the example (UA which generates thumbnails based on 'snapshotTime' at the left, UA which doesn't generate thumbnails based on 'snapshotTime' at the right, e.g. a static viewer).

Example: 05_22.svg

<svg xmlns="http://www.w3.org/2000/svg" version="1.2" baseProfile="tiny"
     viewBox="0 0 400 300" snapshotTime="3">

  <title>Snapshot time example</title>
  <desc>This example shows the use of snapshotTime on an animation of color.</desc>

  <rect x="60" y="85" width="256" height="65" fill="none" stroke="rgb(60,126,220)" stroke-width="4"/>
    
  <text x="65" y="140" fill="white" font-size="60">
    Hello SVG
    <animateColor attributeName="fill" begin="0" dur="3" from="white" to="rgb(60,126,220)"/>  
  </text> 
</svg>

5.2 Grouping: the 'g' element

5.2.1 Overview

The 'g' element is a container element for grouping together related graphics elements.

Grouping constructs, when used in conjunction with the 'desc' and 'title' elements, provide information about document structure and semantics. Documents that are rich in structure may be rendered graphically, as speech, or as braille, and thus promote accessibility.

A group of elements, as well as individual objects, can be given a name using the 'id' or 'xml:id' attribute. Named groups are needed for several purposes such as animation and re-usable objects.

An example:

Example: 05_05.svg

<?xml version="1.0"?>
<svg xmlns="http://www.w3.org/2000/svg" version="1.2" baseProfile="tiny"
     width="5cm" height="5cm" viewBox="0 0 5 5">

  <desc>Two groups, each of two rectangles</desc>

  <g xml:id="group1" fill="red">
    <desc>First group of two red rectangles</desc>
    <rect x="1" y="1" width="1" height="1"/>
    <rect x="3" y="1" width="1" height="1"/>
  </g>
  <g xml:id="group2" fill="blue">
    <desc>Second group of two blue rectangles</desc>
    <rect x="1" y="3" width="1" height="1"/>
    <rect x="3" y="3" width="1" height="1"/>
  </g>

  <!-- Show outline of canvas using 'rect' element -->
  <rect x=".01" y=".01" width="4.98" height="4.98"
        fill="none" stroke="blue" stroke-width=".02"/>
</svg>

A 'g' element can contain other 'g' elements nested within it, to an arbitrary depth. Thus, the following is possible:

Example: 05_06.svg

<?xml version="1.0"?>
<svg xmlns="http://www.w3.org/2000/svg" version="1.2" baseProfile="tiny"
     width="5cm" height="5cm">

  <desc>Groups can nest</desc>

  <g>
    <g>
      <g>
      </g>
    </g>
  </g>
</svg>

Any element that is not contained within a 'g' is treated (at least conceptually) as if it were in its own group.

5.2.2 The 'g' element

Schema: g

    <define name='g'>
      <element name='g'>
        <ref name='g.AT'/>
        <zeroOrMore><ref name='svg.G.group'/></zeroOrMore>
      </element>
    </define>

    <define name='g.AT' combine='interleave'>
      <ref name='svg.Properties.attr'/>
      <ref name='svg.FocusHighlight.attr'/>
      <ref name='svg.Core.attr'/>
      <ref name='svg.External.attr'/>
      <ref name='svg.Conditional.attr'/>
      <ref name='svg.Focus.attr'/>
      <ref name='svg.Transform.attr'/>
    </define>

Attribute definitions:

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

See attribute definition for description.

Animatable: yes.

Navigation Attributes

See definition.

5.3 The 'defs' element

The 'defs' element is a container element for referenced elements. For understandability and accessibility reasons, it is recommended that, whenever possible, referenced elements be defined inside of a 'defs'. For performance reasons, authors should put the 'defs' element before other document content, so that all resources are available to be referenced.

The content model for 'defs' is the same as for the 'g' element; thus, any element that can be a child of a 'g' can also be a child of a 'defs', and vice versa.

Elements that are descendants of a 'defs' are not rendered directly; they are prevented from becoming part of the rendering tree just as if the 'defs' element were a 'g' element and the 'display' property were set to none. Note, however, that the descendants of a 'defs' are always present in the source tree and can be referenced by other elements. The actual value of the 'display' property on the 'defs' element or any of its descendants does not change the rendering of these elements or prevent these elements from being referenced.

Schema: defs

    <define name='defs'>
      <element name='defs'>
        <ref name='defs.AT'/>
        <zeroOrMore><ref name='svg.G.group'/></zeroOrMore>
      </element>
    </define>

    <define name='defs.AT' combine='interleave'>
      <ref name='svg.Properties.attr'/>
      <ref name='svg.Core.attr'/>
    </define>

Creators of SVG content are encouraged to place all elements which are targets of local IRI references (except of course for animation targets) within a 'defs' element which is a direct child of one of the ancestors of the referencing element. For example:

Example: 05_10.svg

<?xml version="1.0"?>
<svg xmlns="http://www.w3.org/2000/svg" version="1.2" baseProfile="tiny"
     width="100%" height="100%" viewBox="0 0 8 3">     

  <desc>Local URI references within ancestor's 'defs' element.</desc>

  <defs>
    <linearGradient xml:id="Gradient01">
      <stop offset="0.2" stop-color="#39F"/>
      <stop offset="0.9" stop-color="#F3F"/>
    </linearGradient>
  </defs>

  <rect x="1" y="1" width="6" height="1" fill="url(#Gradient01)"/>

  <!-- Show outline of canvas using 'rect' element -->
  <rect x=".01" y=".01" width="7.98" height="2.98"
        fill="none" stroke="blue" stroke-width=".02" />
</svg>

In the document above, the linear gradient is defined within a 'defs' element which is the direct child of the 'svg' element, which in turn is an ancestor of the 'rect' element which references the linear gradient. Thus, the above document conforms to the guideline.

5.4 The 'discard' element

The 'discard' element allows authors to specify the time at which particular elements are to be discarded, thereby reducing the resources required by an SVG user agent. This is particularly useful to help SVG viewers conserve memory while displaying long-running documents. This element will not be processed by static SVG viewers.

The 'discard' element may occur wherever the 'animate' element may.

Schema: discard

    <define name='discard'>
      <element name='discard'>
        <ref name='discard.AT'/>
        <ref name='discard.CM'/>
      </element>
    </define>

    <define name='discard.AT' combine='interleave'>
      <ref name='svg.Core.attr'/>
      <ref name='svg.XLink.attr'/>
      <ref name='svg.AnimateBegin.attr'/>
      <ref name='svg.Conditional.attr'/>
    </define>

    <define name='discard.CM'>
      <zeroOrMore>
        <ref name='svg.Desc.group'/>
        <ref name='svg.Handler.group'/>
      </zeroOrMore>
    </define>

Attribute definitions:

xlink:href = "<IRI>"

An IRI reference that identifies the target element to discard. See the definition of 'xlink:href' on animation elements for details on identifying a target element.

Note that if the target element is not part of the current SVG document fragment then whether the target element will be removed or not is defined by the host language.

If the 'xlink:href' attribute is not provided, then the target element will be the immediate parent element of the discard element.

Animatable: no.

begin = "begin-value-list"

Indicates when the target element will be discarded. See the definition of 'begin' on animation elements for details.

The lacuna value is '0s'. This indicates that the target element should be discarded immediately once the document begins.

Animatable: no.

The 'discard' element has an implicit simple duration of "indefinite". As soon as the element's active duration starts, the SVG user agent discards the element identified by the 'xlink:href' attribute ([SMIL21], section 10.4.3). The removal operation acts as if the method removeChild were called on the parent of the target element with the target element as parameter. The SVG user agent must remove the target node as well as all of its attributes and descendants.

After removal of the target element, the 'discard' element is no longer useful. It must also be discarded following the target element removal. If the 'xlink:href' attribute has an invalid IRI reference (the target element did not exist, for example), the 'discard' element itself must still be removed following activation.

Seeking backwards in the timeline ([SMIL21], section 10.4.3) must not re-insert the discarded elements. Discarded elements are intended to be completely removed from memory. So, authors are encouraged to set the 'playbackOrder' attribute to "forwardOnly" when using the 'discard' element.

The 'discard' element itself can be discarded prior to its activation, in which case it will never trigger the removal of its own target element. SVG user agents must allow the 'discard' element to be the target of another 'discard' element.

The following example demonstrates a simple usage of the 'discard' element. The list below describes relevant behavior in the document timeline of this example:

At time = 0:: When the document timeline starts, the blue ellipse starts to move down the page.
At time = 1 second:: The red rectangle starts moving up the page.
At time = 2 seconds:: The 'animateTransform' on the 'ellipse' ends. The 'ellipse' and its children are also discarded, as it is the target element of a 'discard' with begin="2". The green 'polygon' starts to move across the page.
At time = 3 seconds:: The animation on the red rectangle ends. The rectangle and its children are discarded as it is the target of a 'discard' element with begin="3".
At time = 4 seconds:: The animation on the green triangle ends. The green 'polygon' and its children are discarded as it is the target of a 'discard' element with begin="4".

Example: discard01.svg

<?xml version="1.0"?>
<svg xmlns="http://www.w3.org/2000/svg" version="1.2" baseProfile="tiny" 
     width="352" height="240" playbackOrder="forwardOnly">
    
  <ellipse cx="98.5" cy="17.5" rx="20.5" ry="17.5" fill="blue" stroke="black" 
           transform="translate(9 252) translate(3 -296)">
    <animateTransform attributeName="transform" begin="0s" dur="2s" fill="remove"
                      calcMode="linear" type="translate" additive="sum"
                      from="0 0" to="-18 305"/>
    <discard begin="2s"/>
  </ellipse>
  
  <rect x="182" y="-39" width="39" height="30" fill="red" stroke="black"
        transform="translate(30 301)">
    <animateTransform attributeName="transform" begin="1s" dur="2s" fill="remove"
                      calcMode="linear" type="translate" additive="sum"
                      from="0 0" to="-26 -304"/>
    <discard begin="3s"/>
  </rect>
  
  <polygon points="-66,83.5814 -43,123.419 -89,123.419" fill="green" stroke="black" 
           transform="matrix(1 0 0 1.1798 0 -18.6096)">
    <animateTransform attributeName="transform" begin="2s" dur="2s"
                      fill="remove" calcMode="linear" type="translate" additive="sum"
                      from="0 0" to="460 63.5699"/>
    <discard begin="4s"/>
  </polygon>
</svg>

5.5 The 'title' and 'desc' elements

Each container element or graphics element in an SVG document may contain one or more of each of the 'title' and 'desc' descriptive elements, which together comprise a sort of heading and summary of the containing element. The 'title' element must contain a brief plain text passage representing the title for the container or graphics element containing it. This short title must provide information supplementary to the rendering of the element, but will normally not be sufficient to replace it. The 'desc' element must contain a longer, more detailed plain text description for the container or graphics element containing it. This description, along with the content of the 'title' element, must be usable as replacement content for cases when the user cannot see the rendering of the SVG element for whatever reason.

Authors should always provide at least a 'title', and preferably a 'desc', as an immediate child element to the 'svg' element within an SVG document, and to every significant individual graphical composition within the document. The 'title' child element to an 'svg' element serves the purposes of identifying the content of the given SVG document fragment. Since users often consult documents out of context, authors should provide context-rich titles. Thus, instead of a title such as "Introduction", which doesn't provide much contextual background, authors should supply a title such as "Introduction to Medieval Bee-Keeping" instead. For reasons of accessibility, SVG user agents should always make the content of the 'title' child element to the 'svg' element available to users (See the User Agent Accessibility Guidelines 1.0 [UAAG]). The mechanism for doing so depends on the SVG user agent (e.g., as a caption, spoken). If for any reason, a graphical presentation of the document is not available, the rootmost descriptive elements may represent the complete document and its purpose in a textual manner, and authors should supply meaningful content accordingly.

When descriptive elements are present, alternate presentations of the document are possible, both visual and aural, which display the 'title' and 'desc' elements but do not display graphics elements.

For both the 'title' and the 'desc' element, the content must be plain text. To provide structured data in other markup languages, authors should use the 'metadata' or 'foreignObject' elements instead, as appropriate. When markup is included as a child of the 'title' or the 'desc', a user agent should present only the text content of the descriptive elements.

Note that the 'title' element is distinct in purpose from the 'xlink:title' attribute of the 'a' element. The 'xlink:title' attribute content is intended not to describe the current resource, but the nature of the linked resource.

Schema: title

    <define name='title'>
      <element name='title'>
        <ref name='DTM.AT'/>
        <ref name='DTM.CM'/>
      </element>
    </define>

Schema: desc

    <define name='desc'>
      <element name='desc'>
        <ref name='DTM.AT'/>
        <ref name='DTM.CM'/>
      </element>
    </define>

    <define name='DTM.AT' combine='interleave'>
      <ref name='svg.Core.attr'/>
      <ref name='svg.Conditional.attr'/>
      <ref name='svg.Media.attr'/>
    </define>

    <define name='DTM.CM'>
      <text/>
    </define>

5.5.1 Applicable 'title' and 'desc'

Normally, the descriptive elements that describe a container element or graphics element are direct children of that element. However, SVG documents can have a rich structure, with nested elements each potentially containing 'title' or 'desc' child elements, as well as 'use' elements with 'title' or 'desc' in both the 'use' element itself and in the referenced content. Because of this complex structure, and because the descriptive elements may or may not be present at any given level, the applicable descriptive elements for any given content is determined by the structure, as described here.

For each container element or graphics element, the applicable descriptive elements shall be those which are most shallowly nested in that document fragment, without taking into account descriptive elements in any 'use' element shadow trees. If the document fragment has no descriptive elements, and it is a 'use' element, the applicable descriptive elements shall be those contained in the shadow tree. If no descriptive elements are found in the document fragment or any shadow tree, the applicable descriptive elements shall be the nearest ancestor descriptive elements. This algorithm allows authors to reuse descriptive elements defined in referenced resources when desired, or to override them as needed, as well as to describe whole groups of elements. Note that the 'title' and 'desc' are not necessarily always paired (i.e., in the same document hierarchy level), and if the user agent should stop searching for an applicable descriptive element if only one or the other is encountered at a particular hierarchy level.

Note that the applicable descriptive elements for elements in a container element does not necessarily entail a description of the individual graphical elements in question, but rather their membership in a more inclusive group (e.g., if the image is of a basket of fruit, with a title of "Fruit Basket" for the containing group and no other descriptive elements, while no one piece of fruit is a fruit basket, the title would still be applicable through inclusion). In essence, there is a difference between container elements and graphics elements when it comes to determining the applicability of a descriptive element; a 'title' or 'desc' for a graphics element should be assumed to apply only to that element, while a 'title' or 'desc' for a 'g' may apply to each of the children of that group. Authors should take care to designate all important elements with their own descriptive elements to avoid misconstrued identities and entailments.

5.5.2 Multiple 'title' and 'desc' elements

It is strongly recommended that authors use at most one 'title' and at most one 'desc' element as an immediate child of any particular element, and that these elements appear before any other child elements (except possibly 'metadata' elements) or character data content.

Authors may wish to deliberately provide multiple descriptive elements, such as to provide alternate content for different languages. In this case, the author should use conditional processing attributes to allow the user agent to select the best choice according to the user's preferences. For example, the 'systemLanguage' attribute, with or without the 'switch' element, will determine the applicable descriptive elements.

If an SVG user agent needs to choose among multiple 'title' or 'desc' elements for processing (e.g., to decide which string to use for a tooltip), and if any available conditional processing attributes are insufficient to resolve the best option, the user agent must choose the first of each of the available descriptive elements as the applicable 'title' and 'desc'.

5.5.3 User interface behavior for 'title' and 'desc'

When the current SVG document fragment is rendered as SVG on visual media, 'title' and 'desc' elements are not rendered as part of the canvas. Often, the intent of authors is for descriptive elements to remain hidden (e.g., for aesthetic reasons in pieces of art). However, other authors may wish for this content to be displayed, and providing tangible benefit to these authors encourages best practice in providing descriptive elements. In this case, authors are encouraged to use the 'role' attribute, with the value tooltip ([ARIA], section 4.4.1) to indicate their intent. Future SVG specifications may define an explicit mechanism for indicating whether a tooltip should be displayed.

In order to honor authorial intent, it is strongly recommended that when, and only when, the appropriate 'role' attribute value is present, user agents display the text content of the applicable 'title' and 'desc' elements in a highly visible manner supported by the user agent, such as in a tooltip or status bar, when the pointing device is hovered over the described element or elements, or when the described element is given focus (e.g., through keyboard or pointer navigation). If a tooltip is provided, the user agent is recommended to display the applicable title and descriptions on separate lines, title first, with font styling that distinguishes the two. For long descriptions, the tooltip may wrap the text, and truncate longer passages to a reasonable length. A user agent may preserve spaces and line breaks in the text content in order to structure the presentation of the text.

When an element with descriptive elements is itself the child of an 'a' element with an 'xlink:title' attribute, the user agent should display as much of the available information as possible. The user agent is suggested to display the 'xlink:title' attribute value on a separate line, with a label to identify it, such as "link: ". Commonly, many user agents display the URI of the link (i.e., the value of the 'xlink:href' attribute) in the status bar or other display area. This information is important, and should not be overridden by any descriptive element content, but may be supplemented by such content.

The rootmost 'title' element should be used as the document title, and for stand-alone SVG documents, the title should not be displayed as a tooltip, but rather in the browser chrome (as appropriate for the user agent). For embedded SVG documents, such as an SVG image referenced in an HTML document, displaying the rootmost title and description as a tooltip is more appropriate, and the user agent should do so.

If a user agent is an accessibility tool, all available descriptions of the currently focused or hovered element should be exposed to the user in a categorical manner, such that the user may selectively access the various descriptions. The 'desc' element, in particular, may be given different semantic distinctions by use of values in the 'role' attribute, such as the ARIA ontology value description ([ARIA], section 4.4.1) for textual equivalents of the graphics (the default role).

The following is an example in which an SVG user agent might present the 'title' and 'desc' elements as a tooltip.

Example: title-desc-tooltip.svg

<svg xmlns="http://www.w3.org/2000/svg"
     xmlns:xlink="http://www.w3.org/1999/xlink"
     version="1.2"
     width="100%" height="100%" viewBox="0 0 160 170">

  <title>Titles and Descriptions</title>
  <desc>An example of how the contents of the 'title' and 'desc' elements may be presented in a user agent.</desc>

  <defs>
    <polygon id="beeCell" points="-14,-24.2487 14,-24.2487 28,0 14,24.2487 -14,24.2487 -28,0" stroke="yellow" stroke-width="3" stroke-linejoin="round">
      <title role="tooltip">Beehive cell</title>
      <desc role="tooltip">A simple hexagon with a yellow outline and no fill.</desc>
    </polygon>
  </defs>

  <g fill="white">
    <use xlink:href="#beeCell" x="30" y="60" />
    <use xlink:href="#beeCell" x="75" y="34.0192" />
    <use xlink:href="#beeCell" x="120" y="60" />
    <use xlink:href="#beeCell" x="120" y="111.9615" />
    <use xlink:href="#beeCell" x="30" y="111.9615" />
    <use xlink:href="#beeCell" x="75" y="137.9423" />

    <a xlink:href="http://www.example.com/bees.html" xlink:title="Beekeeper's Hive: an apiary resource">
      <title role="tooltip">Link to Beekeeper's Hive: an apiary resource</title>
      <use xlink:href="#beeCell" x="75" y="85.9808" fill="#9900CC">
        <title role="tooltip">Queen's Cell</title>
        <desc role="tooltip">
          A hexagonal beehive cell.
          
          A purple hexagon in the middle of 6 other empty hexagons, symbolizing that it's filled with royal jelly.
        </desc>
      </use>
    </a>  
     
  </g>

</svg>

5.6 The 'use' element

Any 'g' or graphics element is potentially a template object that can be re-used (i.e. "instantiated") in the SVG document via a 'use' element, thus creating an instance tree. The 'use' element references another element and indicates that the graphical contents of that element is to be included and drawn at that given point in the document.

Unlike 'animation', the 'use' element cannot reference entire files.

Besides what is described about the 'use' element in this section important restrictions for 'use' can be found in the Reference Section.

The 'use' element has optional attributes 'x' and 'y' which are used to place the referenced element and its contents into the current coordinate system.

The effect of a 'use' element is as if the SVG element contents of the referenced element were deeply cloned into a separate non-exposed DOM tree which had the 'use' element as its parent and all of the 'use' element's ancestors as its higher-level ancestors. Because the cloned DOM tree is non-exposed, the SVG Document Object Model (DOM) only contains the 'use' element and its attributes. The SVG DOM does not show the referenced element's contents as children of the 'use' element. The deeply-cloned tree, also referred to as the shadow tree, is then 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 the 'use' element's deeply-cloned tree.

Relative IRIs on a node in a shadow tree are resolved relative to any 'xml:base' on the node itself, then recursively on any 'xml:base' on its parentNode, and finally any 'xml:base' on the ownerDocument if there is no parentNode.

Property inheritance works as if the referenced element had been textually included as a deeply cloned child of the 'use' element. The referenced element inherits properties from the 'use' element and the 'use' element's ancestors. An instance of a referenced element does not inherit properties from the referenced element's original parents.

The behavior of the 'visibility' property conforms to this model of property inheritance. Thus, a computed value of visibility="hidden" on a 'use' element does not guarantee that the referenced content will not be rendered. If the 'use' element has a computed value of visibility="hidden" and the element it references specifies visibility="hidden" or visibility="inherit", then that element will be hidden. However, if the referenced element instead specifies visibility="visible", then that element will be visible even if the 'use' element specifies visibility="hidden".

If an event listener is registered on a referenced element, then the actual target for the event will be the SVGElementInstance object within the "instance tree" corresponding to the given referenced element.

The event handling for the non-exposed tree works as if the referenced element had been textually included as a deeply cloned child of the 'use' element, except that events are dispatched to the SVGElementInstance objects. The event's target and currentTarget attributes are set to the SVGElementInstance that corresponds to the target and current target elements in the referenced subtree. An event propagates through the exposed and non-exposed portions of the tree in the same manner as it would in the regular document tree: first going to the target of the event, then bubbling back through non-exposed tree to the 'use' element and then back through regular tree to the rootmost 'svg' element in the bubbling phase.

An element and all its corresponding SVGElementInstance objects share an event listener list. The currentTarget attribute of the event can be used to determine through which object an event listener was invoked.

Animations on a referenced element will cause the instances to also be animated.

As listed in the Reference Section the 'use' element is not allowed to reference an 'svg' element.

Except for resolution of relative IRI references as noted and until the referenced elements are modified, a 'use' element has the same visual effect as if the 'use' element were replaced by the following generated content:

In the generated content, the 'use' will be replaced by 'g', where all attributes from the 'use' element except for 'x', 'y', 'xml:base' and 'xlink:href' are transferred to the generated 'g' element. An additional transformation translate(x,y) is appended to the end (i.e., right-side) of the 'transform' attribute on the generated 'g', where x and y are the values of the 'x' and 'y' attributes of the 'use' element. The referenced object and its contents are deep-cloned into the generated tree.

Note also that any changes to the used element are immediately reflected in the generated content.

When a 'use' references another element which is another 'use' or whose content contains a 'use' element, then the deep cloning approach described above is recursive. However, a set of references that directly or indirectly reference a element to create a circular dependency is an error, as described in the References section.

Schema: use

    <define name='use'>
      <element name='use'>
        <ref name='use.AT'/>
        <ref name='use.CM'/>
      </element>
    </define>

    <define name='use.AT' combine='interleave'>
      <ref name='svg.Properties.attr'/>
      <ref name='svg.FocusHighlight.attr'/>
      <ref name='svg.Core.attr'/>
      <ref name='svg.Conditional.attr'/>
      <ref name='svg.Transform.attr'/>
      <ref name='svg.XLinkEmbed.attr'/>
      <ref name='svg.Focus.attr'/>
      <ref name='svg.External.attr'/>
      <ref name='svg.XY.attr'/>
    </define>

    <define name='use.CM'>
      <zeroOrMore>
        <choice>
          <ref name='svg.Desc.group'/>
          <ref name='svg.Animate.group'/>
          <ref name='svg.Handler.group'/>
        </choice>
      </zeroOrMore>
    </define>

Attribute definitions:

x = "<coordinate>"

The x-axis coordinate of one corner of the rectangular region into which the referenced element is placed.

The lacuna value is '0'.

Animatable: yes.

y = "<coordinate>"

The y-axis coordinate of one corner of the rectangular region into which the referenced element is placed.

The lacuna value is '0'.

Animatable: yes.

xlink:href = "<IRI>"

An IRI reference to an element/fragment within an SVG document. An invalid IRI reference is an unsupported value. An empty attribute value (xlink:href="") disables rendering of the element. The lacuna value is the empty string.

Animatable: yes.

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

See attribute definition for description.

Animatable: yes.

Navigation Attributes

See definition.

Below are two examples of the 'use' element. For another example see use and animation example.

Example 05_13 below has a simple 'use' on a 'rect'.

Example: 05_13.svg

<?xml version="1.0"?>
<svg xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink"
     version="1.2" baseProfile="tiny"
     width="10cm" height="3cm" viewBox="0 0 100 30">     

  <desc>Simple case of 'use' on a 'rect'</desc>

  <defs>
    <rect xml:id="MyRect" width="60" height="10"/>
  </defs>
  <rect x=".1" y=".1" width="99.8" height="29.8"
        fill="none" stroke="blue" stroke-width=".2"/>
  <use x="20" y="10" xlink:href="#MyRect" />
</svg>

The visual effect would be equivalent to the following document:

Example: 05_14.svg

<?xml version="1.0"?>
<svg xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink" 
     version="1.2" baseProfile="tiny"
     width="10cm" height="10cm" viewBox="0 0 100 30">

  <desc>
    The equivalent rendering tree of example 05_13 once the
    'use' element's shadow tree has been created.
  </desc>

  <!-- 'defs' section left out -->

  <rect x=".1" y=".1" width="99.8" height="29.8"
        fill="none" stroke="blue" stroke-width=".2" />

  <!-- begin shadow tree content that the <use> element in the original
       file would generate -->
  <g transform="translate(20,10)">
    <rect width="60" height="10"/>
  </g>
  <!-- end of shadow tree content -->
</svg>

Example 05_17 illustrates what happens when a 'use' has a 'transform' attribute.

Example: 05_17.svg

<?xml version="1.0"?>
<svg xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink"
     version="1.2" baseProfile="tiny"
     width="10cm" height="3cm" viewBox="0 0 100 30">

  <desc>'use' with a 'transform' attribute</desc>

  <defs>
    <rect xml:id="MyRect" x="0" y="0" width="60" height="10"/>
  </defs>

  <rect x=".1" y=".1" width="99.8" height="29.8"
        fill="none" stroke="blue" stroke-width=".2"/>
  <use xlink:href="#MyRect" transform="translate(20,2.5) rotate(10)"/>
</svg>

The visual effect would be equivalent to the following document:

Example: 05_18.svg

<?xml version="1.0"?>
<svg xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink"
     version="1.2" baseProfile="tiny"
     width="100%" height="100%" viewBox="0 0 100 30">

  <desc>'use' with a 'transform' attribute</desc>

  <!-- 'defs' section left out -->

  <rect x=".1" y=".1" width="99.8" height="29.8"
        fill="none" stroke="blue" stroke-width=".2"/>

  <!-- begin shadow tree content that the <use> element in the original
       file would generate -->
  <g transform="translate(20,2.5) rotate(10)">
    <rect x="0" y="0" width="60" height="10"/>
  </g>
  <!-- end of shadow tree content-->
</svg>

Example use-bubble-example-1.svg illustrates four cases of event bubbling with use elements. In case 1, all instances of the 'rect' element are filled blue on mouse over. For cases 2 and 3, in addition to the 'rect' elements being filled blue, a black stroke will also appear around the referencing rectangle on mouse over. In case 4, all the rectangles turn blue on mouse over, and a black stroke appears on mouse click.

Example: use-bubble-example-1.svg

<?xml version="1.0"?>
<svg xmlns="http://www.w3.org/2000/svg"
     xmlns:xlink="http://www.w3.org/1999/xlink"
     xmlns:ev="http://www.w3.org/2001/xml-events"
     version="1.2" baseProfile="tiny">

  <defs>
    <rect id="rect" width="20" height="20" fill="red">
      <set attributeName="fill" begin="mouseover" end="mouseout" to="blue"/>
    </rect>
  </defs>

  <use fill="red" x="5" y="5" xlink:href="#rect"/>
  <text x="10" y="35">1</text>
  
  <use id="use2" fill="red" x="30" y="5" xlink:href="#rect"/>  
  <rect pointer-events="none" x="30" y="5" width="20" height="20"
        fill="none" stroke-width="3" stroke="none">
    <set attributeName="stroke" begin="use2.mouseover" end="use2.mouseout" to="black"/>
  </rect>
  <text x="35" y="35">2</text>
  
  <g id="g1">
    <use fill="red" x="5" y="40" xlink:href="#rect"/>  
    <rect pointer-events="none" x="5" y="40" width="20" height="20"
          fill="none" stroke-width="3" stroke="none">
      <set attributeName="stroke" begin="g1.mouseover" end="g1.mouseout" to="black"/>
    </rect>
  </g>
  <text x="10" y="70">3</text>
  
  <use id="use3" fill="red" x="30" y="40" xlink:href="#rect"/>  
  <rect pointer-events="none" x="30" y="40" width="20" height="20"
        fill="none" stroke-width="3" stroke="none">
    <set attributeName="stroke" begin="use3.click" dur="500ms" to="black"/>
  </rect>  
  <text x="35" y="70">4</text>
</svg>

Example use-bubble-example-2.svg illustrates event bubbling with nested 'use' elements. On mouse over, the 'rect' element is filled blue and displays a green and black ring.

Example: use-bubble-example-2.svg

<?xml version="1.0"?>
<svg xmlns="http://www.w3.org/2000/svg"
     xmlns:xlink="http://www.w3.org/1999/xlink"
     xmlns:ev="http://www.w3.org/2001/xml-events"
     version="1.2" baseProfile="tiny">

  <defs>
    <rect id="rect" width="20" height="20" fill="red">
      <set attributeName="fill" begin="mouseover" end="mouseout" to="blue"/>
    </rect>    
    <g id="use">
      <use fill="red" xlink:href="#rect"/>  
      <rect pointer-events="none" width="20" height="20"
            fill="none" stroke-width="8" stroke="none">
        <set attributeName="stroke" begin="use.mouseover" end="use.mouseout" to="green"/>
      </rect>
    </g>
  </defs>
  
  <use x="5" y="5" id="use2" fill="red" xlink:href="#use"/>  
  <rect pointer-events="none" x="5" y="5" width="20" height="20" fill="none" stroke-width="3" stroke="none">
    <set attributeName="stroke" begin="use2.mouseover" end="use2.mouseout" to="black"/>
  </rect>
</svg>

Example image-use-base.svg illustrates the handling of relative IRI references. All three use elements result in the same image being displayed, http://a.example.org/aaa/bbb/ddd/foo.jpg.

Example: image-use-base.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="1.2" baseProfile="tiny" viewBox="00 100 100">

  <g xml:base="http://a.example.org/aaa/">
    <g xml:base="/bbb/ccc/">
      <g xml:base="../ddd/" xml:id="bar">
        <image xml:id="foo" xlink:href="foo.jpg" width="100" height="100"/>
      </g>
    </g>
  </g>
  <g xml:base="http://z.example.net/zzz/">
    <g xml:base="/yyy/xxx/">
      <g xml:base="../xxx/">
        <use xlink:href="#foo" />
        <use xlink:href="#bar" />
        <use xlink:href="#bar" xml:base="../ggg/" />
      </g>
    </g>
  </g>
</svg>

5.7 The 'image' element

The 'image' element indicates that the contents of an image are to be rendered into a given rectangle within the current user coordinate system. In SVG Tiny 1.2, the 'image' must reference content that is a raster image format, such as PNG or JPEG [PNG, JPEG]. SVG Tiny 1.2 does not allow an SVG document to be referenced by the 'image' element; instead, authors should use the 'animation' element for referencing SVG documents. Conforming SVG viewers must support PNG and JPEG image file formats. Other image file formats may be supported.

For details of the required JPEG support see the JPEG Support appendix. PNG support is required as defined in the Portable Network Graphics (PNG) Specification (Second Edition) [PNG].

The result of processing an 'image' is always a four-channel RGBA result. When an 'image' element references a raster image file such as PNG or JPEG files which only has three channels (RGB), then the effect is as if the object were converted into a 4-channel RGBA image with the alpha channel uniformly set to 1. For a single-channel raster image, the effect is as if the object were converted into a 4-channel RGBA image, where the single channel from the referenced object is used to compute the three color channels and the alpha channel is uniformly set to 1.

The 'image' element supports the 'opacity' property for controlling the image opacity. The 'fill-opacity' property does not affect the rendering of an image.

An 'image' element establishes a new viewport for the referenced file as described in Establishing a new viewport. The bounds for the new viewport are defined by attributes 'x', 'y', 'width' and 'height'. The placement and scaling of the referenced image are controlled by the 'preserveAspectRatio' attribute on the 'image' element.

The value of the 'viewBox' attribute to use when evaluating the 'preserveAspectRatio' attribute is defined by the referenced content. For content that clearly identifies a 'viewBox' that value should be used. For most raster content (such as PNG and JPEG) the bounds of the image should be used (i.e. the 'image' element has an implicit 'viewBox' of "0 0 raster-image-width raster-image-height"). Where no value is readily available the 'preserveAspectRatio' attribute is ignored and only the translate due to the 'x' and 'y' attributes of the viewport is used to display the content.

For example, if the 'image' element referenced a PNG or JPEG and preserveAspectRatio="xMinYMin meet", then the aspect ratio of the raster would be preserved (which means that the scale factor from the image's coordinates to the current user space coordinates would be the same for both x and y), the raster would be sized as large as possible while ensuring that the entire raster fits within the viewport, and the top left of the raster would be aligned with the top left of the viewport as defined by the attributes 'x', 'y', 'width' and 'height' on the 'image' element. If the value of 'preserveAspectRatio' was "none" then aspect ratio of the image would not be preserved. The image would be positioned such that the top-left corner of the raster exactly aligns with coordinate ('x', 'y') and the bottom-right corner of the raster exactly aligns with coordinate ('x'+'width', 'y'+'height').

The SVG specification does not specify when an image that is not being displayed should be loaded. An SVG user agent is not required to load image data for an image that is not displayed (e.g. an image which is outside the initial document viewport), except when that image is contained inside a subtree for which 'externalResourcesRequired' is set to "true". However, it should be noted that this may cause a delay when an image becomes visible for the first time. In the case where an author wants to suggest that the SVG user agent loads image data before it is displayed, they should use the 'prefetch' element.

Note that an SVG user agent may choose to incrementally render an image as it is loading but is not required to do so.

Schema: image

    <define name='image'>
      <element name='image'>
        <ref name='image.AT'/>
        <ref name='image.CM'/>
      </element>
    </define>

    <define name='image.AT' combine='interleave'>
      <ref name='svg.Core.attr'/>
      <ref name='svg.FocusHighlight.attr'/>
      <ref name='svg.Media.attr'/>
      <ref name='svg.XLinkEmbed.attr'/>
      <ref name='svg.Conditional.attr'/>
      <ref name='svg.External.attr'/>
      <ref name='svg.Focus.attr'/>
      <ref name='svg.Transform.attr'/>
      <ref name='svg.Opacity.attr'/>
      <ref name='svg.XYWH.attr'/>
      <ref name='svg.PAR.attr'/>
      <ref name='svg.ContentTypeAnim.attr'/>
    </define>

    <define name='image.CM'>
      <zeroOrMore>
        <choice>
          <ref name='svg.Desc.group'/>
          <ref name='svg.Animate.group'/>
          <ref name='svg.Discard.group'/>
          <ref name='svg.Handler.group'/>
        </choice>
      </zeroOrMore>
    </define>

Attribute definitions:

x = "<coordinate>"

The x-axis coordinate of one corner of the rectangular region.

The lacuna value is '0'.

Animatable: yes.

y = "<coordinate>"

The y-axis coordinate of one corner of the rectangular region.

The lacuna value is '0'.

Animatable: yes.

width = "<length>"

The width of the rectangular region.

A negative value is unsupported. A value of zero disables rendering of the element. The lacuna value is '0'.

Animatable: yes.

height = "<length>"

The height of the rectangular region.

A negative value is unsupported. A value of zero disables rendering of the element. The lacuna value is '0'.

Animatable: yes.

preserveAspectRatio = "[defer] <align> [<meet>]"

See attribute definition for description.

Animatable: yes.

xlink:href = "<IRI>"

An IRI reference to the image. An invalid IRI reference is an unsupported value. An empty attribute value (xlink:href="") disables rendering of the element. The lacuna value is the empty string.

Animatable: yes.

type = "<content-type>"

A hint about the expected Internet Media Type of the raster image. Implementations may choose to not fetch images of formats that they do not support. Note that if an Internet Media type returned by the server, the server metadata is authoritative over the type attribute. See Metadata hints in specifications in the Authoritative Metadata TAG finding ([MIME-RESPECT], section 5). To ensure that a user agent only downloads media in formats that it supports, thus optimizing download time and bandwidth usage, authors are encouraged to use 'requiredFormats', instead of 'type'.

Animatable: yes.

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

See attribute definition for description.

Animatable: yes.

Navigation Attributes

See definition.

An example:

Example: 05_21.svg

<?xml version="1.0"?>
<svg xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink"
     version="1.2" baseProfile="tiny">

  <desc>This document has a reference to an external image</desc>

  <image x="200" y="200" width="100" height="100" xlink:href="externalImage.png">
    <title>External image</title>
  </image>
</svg>

5.8 Conditional processing

5.8.1 Conditional processing overview

SVG provides a 'switch' element and five conditional processing attributes — 'requiredExtensions', 'requiredFeatures', 'requiredFonts', 'requiredFormats' and 'systemLanguage' — which provide the ability to specify alternate content depending on the capabilities of a given SVG user agent or the user's language.

Schema: conditional

    <define name='svg.Conditional.attr' combine='interleave'>
      <optional>
        <attribute name='requiredFeatures' svg:animatable='false' svg:inheritable='false'>
          <ref name='ListOfIRI.datatype'/>
        </attribute>
      </optional>
      <optional>
        <attribute name='requiredExtensions' svg:animatable='false' svg:inheritable='false'>
          <ref name='ListOfIRI.datatype'/>
        </attribute>
      </optional>
      <optional>
        <attribute name='requiredFormats' svg:animatable='false' svg:inheritable='false'>
          <ref name='FormatList.datatype'/>
        </attribute>
      </optional>
      <optional>
        <attribute name='requiredFonts' svg:animatable='false' svg:inheritable='false'>
          <ref name='FontList.datatype'/>
        </attribute>
      </optional>
      <optional>
        <attribute name='systemLanguage' svg:animatable='false' svg:inheritable='false'>
          <ref name='LanguageIDs.datatype'/>
        </attribute>
      </optional>
    </define>

Conditional processing attributes do not affect the processing of all elements. They can be specified only on graphics elements, container elements, text content elements, descriptive elements, timed elements and the 'foreignObject' and 'discard' elements. A conditional processing attribute on any other element does not affect whether that element will be processed. When a conditional processing attribute is specified on a container element, it affects only the elements on which conditional processing attributes can be specified. For example, a 'requiredExtensions' attribute on a 'script' element will not control whether the script is executed. Note that if a conditional processing attribute is specified on a container element which contains scripts, it has no effect on whether the script is executed. In particular, all scripts contained in a 'switch' element are processed.

The conditional processing attributes act as boolean tests and evaluate to either true or false. If one is not specified, then it is assumed to evaluate to true. The attributes can be used in two ways, depending on the context of the element on which the attributes are specified. If the element's parent node is a 'switch' element, then at most one of the 'switch' element's children that conditional processing attributes apply to will be processed. (See the description of the 'switch' element for details.) Otherwise, if the element's parent node is not a 'switch' element, and conditional processing attributes do apply to the element, then the attributes determine whether that element will be processed.

What it means for an element not to be processed because of conditional processing attributes specified on it, or because it is a child of a 'switch' that has selected a different child for processing, depends on the type of element:

If the element is a graphics element, container element, text content element or a 'foreignObject' element, then the element is not rendered and is not a part of the rendering tree.
If the element is a timed element, then the element will never begin, regardless of its timing attributes and any invocations of methods on the SVGTimedElement and ElementTimeControl interfaces. If the element serves as a syncbase for any other timed elements in the document, then those syncbase references will never resolve to a concrete time. Thus, for example, if the element is an animation element, the animation will never have an effect, and if the element is an 'audio' element, then it will never generate any sound.
If the element is a 'discard' element, then it will never trigger the removal of its target element, nor will it remove itself.

Similar to the 'display' property, conditional processing attributes only affect the direct rendering and processing of applicable elements and do not prevent elements from being successfully referenced by other elements (such as via a 'use'). Conditional processing attributes in a shadow tree are processed normally.

Example systemLanguage below displays one of three text strings (in Welsh, Greek, or Spanish) if one of those is the user's preferred language. Otherwise, in this example, it displays nothing.

Example: systemLanguage.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="1.2" baseProfile="tiny" viewBox="0 0 170 200">

  <title>systemLanguage example</title>

  <switch>
    <g systemLanguage="cy">
      <text x="20" y="220" xml:lang="cy" font-size="20">Pam dydyn nhw ddim yn
        siarad Cymraeg?</text>
    </g>
    <g systemLanguage="el">
      <text x="20" y="220" xml:lang="el-GR" font-size="22">Μα γιατί δεν μπορούν
        να μιλήσουν Ελληνικά ;</text>
    </g>
    <g systemLanguage="es">
      <text x="20" y="220" xml:lang="es-ES" font-size="18">¿Por qué no pueden
        simplemente hablar en castellano?</text>
    </g>
  </switch>
</svg>

5.8.2 The 'switch' element

The 'switch' element is a container element that can be used to select one of its child elements to process based on their conditional processing attributes. The first direct child element of a 'switch' whose conditional processing attributes all evaluate to true will be processed as normal. All other direct child elements of the 'switch' that support conditional processing attributes will not be processed. The elements that support conditional processing attributes are listed in the Conditional processing overview section, above.

While conditional processing attributes are supported only on certain elements, those attributes on all direct child elements of a 'switch' are used to determine which children to disable processing for.

The values of the 'display' and 'visibility' properties have no effect on 'switch' element processing. In particular, setting 'display' to none on a child of a 'switch' element has no effect on the testing associated with 'switch' element processing.

Note that regardless of whether they are processed or disabled, child elements of the 'switch' element are still part of the DOM, and rules applying to the uniqueness of the 'id' and 'xml:id' attributes still apply. Additionally, elements which would not otherwise be rendered due to conditional processing can still be referenced, for example as the target of a 'use' element or as a paint server reference in a 'fill' property.

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

Schema: switch.at

    <define name='switch.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.Transform.attr'/>
      <ref name='svg.Focus.attr'/>
    </define>

For more information and an example, see Embedding foreign object types.

Attribute definitions:

requiredExtensions = "<list-of-strings>"

See attribute definition for description.

Animatable: no.

requiredFeatures = "<list-of-strings>"

See attribute definition for description.

Animatable: no.

requiredFonts = "<list-of-strings>"

See attribute definition for description.

Animatable: no.

requiredFormats = "<list-of-content-types>"

See attribute definition for description.

Animatable: no.

systemLanguage = "<list-of-language-ids>"

See attribute definition for description.

Animatable: no.

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

See attribute definition for description.

Animatable: yes.

Navigation Attributes

See definition.

5.8.3 The 'requiredFeatures' attribute

Definition of 'requiredFeatures':

requiredFeatures = "<list-of-strings>"

A conditional processing attribute that controls conditional processing based on whether the specified features are supported by the SVG user agent. The value is a list of feature strings, with the individual values separated by white space. Only feature strings defined in an existing version of the SVG specification at the time the document is authored (such as those listed in this document's Feature String appendix) should be used, while third party extension features that are not part of an SVG standard should be indicated using the 'requiredExtensions' attribute instead.

This attribute evaluates to true for the purpose of conditional processing if and only if all of the specified features are supported. As with all conditional processing attributes, if 'requiredFeatures' is not specified, then it implicitly evaluates to true. However, if the attribute is specified, but has an empty string value, it evaluates to false. See Conditional processing overview for details on how conditional processing attributes influence document processing.

Animatable: no.

5.8.4 The 'requiredExtensions' attribute

The 'requiredExtensions' attribute specifies a list of required language extensions. Language extensions are capabilities within an SVG user agent that go beyond the feature set defined in this specification. Each extension is identified by an IRI reference.

Language extensions may be vendor-specific or experimental features for the SVG language itself, or may be separate languages (e.g., XHTML, MathML). If an extension is a separate language that supports the Namespaces in XML 1.0 specification [XML-NS10] or the Namespaces in XML 1.1 specification [XML-NS], the IRI reference should be the Namespace URI for that language (e.g., "http://www.w3.org/1999/xhtml", "http://www.w3.org/1998/Math/MathML"). If the language does not support either Namespaces in XML specification, the IRI reference should be an otherwise unique identifier for that language.

Definition of 'requiredExtensions':

requiredExtensions = "<list-of-strings>"

A conditional processing attribute that controls conditional processing based on whether the specified extensions are supported by the SVG user agent. The value is a list of IRI references which identify the required extensions, with the individual values separated by white space.

This attribute evaluates to true for the purpose of conditional processing if and only if all of the specified extensions are supported. As with all conditional processing attributes, if 'requiredExtensions' is not specified, then it implicitly evaluates to true. However, if the attribute is specified, but has an empty string value, it evaluates to false. See Conditional processing overview for details on how conditional processing attribute influence document processing.

Animatable: no.

Since white space is used to separate values in the attribute, any white space characters in the IRI reference must be escaped.

5.8.5 The 'systemLanguage' attribute

Definition of 'systemLanguage':

systemLanguage = "<list-of-language-ids>"

A conditional processing attribute that controls conditional processing based on the system language. The value is a comma-separated list of language tags as defined in BCP 47 ([BCP 47], section 2).

This attribute evaluates to true for the purpose of conditional processing if one of the languages indicated by user preferences equals one of the languages given in the value of this attribute, or if one of the languages indicated by user preferences exactly equals a prefix of one of the languages given in the value of this attribute such that the first tag character following the prefix is U+002D HYPHEN-MINUS ("-"). As with all conditional processing attributes, if 'systemLanguage' is not specified, then it implicitly evaluates to true. However, if the attribute is specified, but has an empty string value, it evaluates to false. See Conditional processing overview for details on how conditional processing attribute influence document processing.

Animatable: no.

Note that the use of a prefix matching rule to determine whether the attribute evaluates to true or false does not imply that language tags are assigned to languages in such a way that it is always true that if a user understands a language with a certain tag, then this user will also understand all languages with tags for which this tag is a prefix. The prefix rule simply allows the use of prefix tags if this is the case.

Implementation note: When making the choice of linguistic preference available to the user, implementers should take into account the fact that users are not familiar with the details of language matching as described above, and should provide appropriate guidance. As an example, users may assume that on selecting "en-GB", they will be served any kind of English document if British English is not available. The user interface for setting user preferences should guide the user to add "en" to get the best matching behavior.

Multiple languages may be listed for content that is intended for multiple audiences. For example, content that is presented simultaneously in the original Maori and English versions, would call for:

<text systemLanguage="mi, en"><!-- content
  goes here --></text>

However, just because multiple languages are present within the element on which the 'systemLanguage' conditional processing attribute is placed, this does not mean that it is intended for multiple linguistic audiences. An example would be a beginner's language primer, such as "A First Lesson in Latin," which is clearly intended to be used by an English-literate audience. In this case, the 'systemLanguage' conditional processing attribute should only include "en".

Authoring note: Authors should realize that if several alternative language objects are enclosed in a 'switch', and none of them matches, this may lead to situations where no content is displayed. It is thus recommended to include a "catch-all" choice at the end of such a 'switch' which is acceptable in all cases.

5.8.6 The 'requiredFormats' attribute

Many resources, especially media such as audio and video, have a wide range of formats. As it is often not possible to require support for a particular format, due to legal or platform restrictions, it is often necessary for content to provide alternatives so that SVG user agents can choose the format they support. The 'requiredFormats' attribute can be used to control conditional processing based on whether a particular format is supported by the user agent.

Definition of 'requiredFormats':

requiredFormats = "<list-of-content-types>"

A conditional processing attribute that controls conditional processing based on whether the specified formats are supported by the SVG user agent. The value is a list of Internet media types, with the individual values separated by white space. For a list of registered Internet media types (formerly called MIME types), see the IANA Media Type registry [MIMETYPES]. For a list of Internet media types types for audio and video codecs, see the IANA codec registry and WAVE and AVI Codec Registries [CODECS, RFC2361].

As with all conditional processing attributes, if 'requiredFormats' is not specified, then it implicitly evaluates to true. However, if the attribute is specified, but has an empty string value, it evaluates to false. See Conditional processing overview for details on how conditional processing attribute influence document processing.

Animatable: no.

The following formats must always evaluate to true in conforming SVG viewers:

image/png
image/jpeg
image/svg+xml

5.8.7 The 'requiredFonts' attribute

If the author wishes to have complete control over the appearance and location of text in the document then they must ensure that the correct font is used when rendering the text. This can be achieved by using SVG fonts and embedding the font in the document. However, this is not practical in all cases, especially when the number of glyphs used is very large or if the licensing of the font forbids such embedding.

Definition of 'requiredFonts':

requiredFonts = "<list-of-family-names>"

A conditional processing attribute that controls conditional processing based on whether the specified fonts are available. The value is a list of font family names, using the same syntax as the 'font-family' property, for example when processing quoted strings, multiple, leading and trailing spaces, and case sensitivity. Generic family names may not be used, however.

This attribute evaluates to true for the purpose of conditional processing if and only if all of the specified fonts are available, either installed on the system or as an SVG font defined or embedded within the document. As with all conditional processing attributes, if 'requiredFonts' is not specified, then it implicitly evaluates to true. However, if the attribute is specified, but has an empty string value, it evaluates to false. See Conditional processing overview for details on how conditional processing attribute influence document processing.

Animatable: no.

5.9 External resources

5.9.1 The 'externalResourcesRequired' attribute

Documents often reference and use the contents of other document and other web resources as part of their rendering or processing. In some cases, authors want to specify that particular resources are required for a document to be considered correct.

The 'externalResourcesRequired' attribute is available on all container elements except 'defs' and on all elements which potentially can reference external resources. It specifies whether referenced resources that are not part of the current document are required for proper rendering of the given element.

Attribute definition:

externalResourcesRequired = "false" | "true"

An attribute that specifies whether external resources are required for correct rendering of this element and its descendants.

false: (The lacuna value.) Indicates that resources external to the current document are optional. Document rendering can proceed even if external resources are unavailable to the current element and its descendants.
true: Indicates that resources external to the current document are required. If an external resource is not available (for example the request for the required resource times out), progressive rendering is suspended, the load event is not fired for the element, and the document becomes in error (see Error processing). The document remains in error until all required resources become available.

Animatable: no.

Attribute 'externalResourcesRequired' is not inheritable (from a sense of attribute value inheritance), but if set on a container element, its value will apply to all elements within the container.

Because setting externalResourcesRequired="true" on a container element will have the effect of disabling progressive display of the contents of that container, if that container includes elements that reference external resources, tools that generate SVG content should normally not just set externalResourcesRequired="true" on the 'svg' element on a universal basis. Instead, it is better to specify externalResourcesRequired="true" on those particular elements which specifically need the availability of external resources in order to render properly.

5.9.2 Progressive rendering

When progressively downloading a document, an SVG user agent conceptually builds a tree of nodes in various states. The possible states for these nodes are unresolved, resolved and error.

This description uses two conceptual parsing events to simplify the prose in explaining the intended behaviour of progressive rendering. The events referred to in the following prose are the start element and end element events. The start element event is considered to be triggered when a start-tag or an empty-element tag is read. The end element event occurs either immediately following the start element event in the case of an empty-element tag, or when an end-tag is read. The terms start-tag, end-tag and empty-element tag are as defined in Extensible Markup Language (XML) 1.0 ([XML10], section 3.1) and Extensible Markup Language (XML) 1.1 ([XML11], section 3.1).

When loading a document following the start element event on a node, that node becomes part of the document tree in the unresolved state. It is appended as the last child of the most recently opened element that is still open (that is, the most recent element for which a start element event has occurred with no corresponding end element event). If the node's dependencies are successfully resolved, then the node enters the resolved state or if the node's dependencies are found to be in error, then the node enters the error state.

When an end element event occurs for a 'script' element, that element is processed according to the Script processing section of the Scripting chapter. Further parsing of the document will be blocked until processing of the 'script' is complete.

Node dependencies include both children content (like the child elements on a 'g') and resources (e.g. images referenced by an 'image') referenced from that node or from its children. Empty elements (elements without children) become resolved when the end element event occurs on the element; elements with child nodes become resolved when all their children are resolved and when the end element event occurs on the element. Resources become resolved (or found in error) by an SVG user agent specific mechanism.

SVG user agents must implement progressive rendering although there is no minimum rendering update frequency required for conformance. Implementations should find their own balance between processing the changes in the document tree and rendering the tree to produce a smooth rendering avoiding significant pauses. The following rules apply to progressive rendering:

The SVG user agent has the opportunity to update the rendering following each start element and/or end element event, i.e. each time the SVG user agent parses a start-tag, empty-element tag or end-tag.
The SVG user agent renders the conceptual document tree nodes in document order up to, and not including the first node in the unresolved state which has 'externalResourcesRequired' set to "true". Nodes in the resolved state are always rendered. Nodes in the unresolved state but with 'externalResourcesRequired' set to "false" are rendered in their current state. If the node has no rendering (e.g., an 'image' pending a resource), then nothing is rendered for that node.
If a node enters the error state then the document enters the error state and progressive rendering stops.

Note that even if the SVG user agent has the opportunity to update the rendering after each start/end element event there are situations where such an update shouldn't be done. For example, 'font' element children ('font-face', 'hkern', 'missing-glyph', 'glyph') should not cause an update of the document rendering, only the end element event on the 'font' element should cause a document rendering as for other node types.

Note that forward referencing from a 'discard' element should be avoided when using progressive rendering. If it fails to find (and thus discard) an element, it will not later discard the element when it has finally loaded.

In Example progRend01 below, the 'g' element rendering may start when the 'g' end-tag has been parsed and processed and when all the resources needed by its children have been resolved. This means that the group's rendering may start when the group has been fully parsed and myImage.png has been successfully retrieved.

Example: progRend01.svg

<svg xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink"
     version="1.2" baseProfile="tiny" viewBox="0 0 480 360">

  <desc>externalResourcesRequired example.</desc>

  <g externalResourcesRequired="true">
    <rect xml:id="rect_1" width="5" height="7"/>
     ...
    <rect xml:id="rect_1000" width="5" height="7"/>

    <image xlink:href="myImage.png" width="5" height="7" externalResourcesRequired="true"/>
    <rect xml:id="rect_1001" width="5" height="7"/>
  </g>
</svg>

Example progRend02 demonstrates how progressive rendering is performed when there is a 'use' element with a forward reference.

Example: progRend02.svg

<svg xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink"
     version="1.2" baseProfile="tiny" viewBox="0 0 480 360">

  <desc>Forward reference of use element</desc>

  <use xlink:href="#myRect" x="200" fill="green"/>
  <circle cx="450" cy="50" r="50" fill="yellow"/>

  <g fill="red">
    <rect xml:id="myRect" width="100" height="100"/>
  </g>
</svg>

The following list shows the possible renderings of the document as it is parsed (the rendering state follows the colon):

'use' → start element: empty
'circle' → start element: yellow circle
'g' → start element: no update
'rect' → start element (use reference becomes resolved): green rect, yellow circle, red rect

Example progRend03 demonstrates how progressive rendering is performed when there is a 'use' element with a forward reference and which has externalResourcesRequired="true".

Example: progRend03.svg

<svg xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink"
     version="1.2" baseProfile="tiny" viewBox="0 0 480 360">

  <desc>Forward reference on use with eRR=true</desc>

  <use xlink:href="#myGroup" x="200" fill="green" externalResourcesRequired="true"/>
  <circle cx="450" cy="50" r="50" fill="yellow"/>

  <g fill="red">
    <g xml:id="myGroup">
      <rect xml:id="myRect" width="100" height="100"/>
      <use xlink:href="#myRect" x="50" fill="purple"/>
    </g>
  </g>
</svg>

The possible rendering states are as follows:

'use' → start element: empty
'circle' → start element: empty 'use' is unresolved, externalResourcesRequired="true", rendering is stopped at the 'use')
Outer 'g' → start element: no update
Inner 'g' → start element: no update (use is resolved but externalResourcesRequired="true" so rendering may not proceed until that reference enters the resolved state)
'rect' → start element: no update
'use' → start element: no update
Inner 'g' → end element (#myGroup reference becomes resolved, rendering can proceed): green rect, purple rect, yellow circle, red rect, purple rect

Example progRend04 shows a 'use' element with a reference to an element that is in a container with externalResourcesRequired="true".

Example: progRend04.svg

<svg xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink"
     version="1.2" baseProfile="tiny" viewBox="0 0 480 360">

  <desc>Forward reference to a use under a container with eRR=true</desc>

  <use xlink:href="#myRect" x="200" fill="green"/>
  <circle cx="250" cy="50" r="50" fill="pink"/>

  <g fill="red" externalResourcesRequired="true">
    <circle cx="450" cy="50" r="50" fill="yellow"/>
    <rect xml:id="myRect" width="100" height="100"/>
  </g>
</svg>

The possible rendering states as the document is parsed are as follows:

'use' → start element: empty
Pink 'circle' → start element: pink circle
'g' → start element: no update (rendering is suspended because of externalResourcesRequired="true" on the 'g' element, i.e. because the children of 'g' are not resolved at the time of parsing of the start tag of the 'g').
Yellow 'circle' → start element: no update (rendering suspended because of 'g')
'rect' → start element: no update
'g' → end element (resources referenced by 'use' become resolved and can be rendered, so rendering can proceed): green rect, pink circle, yellow circle, red rect

Example progRend05 shows an example of progressive rendering with a forward reference to an SVG font. Rendering updates do not occur mid-way through parsing a 'font' element.

Example: progRend05.svg

<svg xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink"
     version="1.2" baseProfile="tiny" viewBox="0 0 480 360">

  <desc>Font Resolution Example</desc>

  <text x="240" y="230" text-anchor="middle" font-size="120"
        font-family="fontC, fontB, fontA">A</text>

  <defs>
    <font xml:id="fontA" horiz-adv-x="224" >
      <font-face
        font-family="fontA"
        units-per-em="1000"
        panose-1="0 0 0 0 0 0 0 0 0 0"
        ascent="917"
        descent="-250"
        alphabetic="0"/>
      <missing-glyph horiz-adv-x="800" d="..." />
      <glyph unicode="A" glyph-name="A"  d="..."/>
    </font>

    <font xml:id="fontB" horiz-adv-x="224">
      <font-face
        font-family="fontB"
        units-per-em="1000"
        panose-1="0 0 0 0 0 0 0 0 0 0"
        ascent="917"
        descent="-250"
        alphabetic="0"/>
      <missing-glyph horiz-adv-x="800" d="..."/>
      <glyph unicode="A" glyph-name="B" d="..." />
    </font>

    <font xml:id="fontC" horiz-adv-x="224" >
      <font-face
        font-family="fontC"
        units-per-em="1000"
        panose-1="0 0 0 0 0 0 0 0 0 0"
        ascent="917"
        descent="-250"
        alphabetic="0"/>
      <missing-glyph d="..."/>
      <glyph unicode="A" glyph-name="C" d="..."/>
    </font>
  </defs>
</svg>

Rendering update possibilities as the document is parsed are as follows:

'text' → start element: "A" rendered with the default font
'defs' → start element: no update
#fontA → start element: no update
#fontA / 'font-face' → start element: no update
#fontA / 'missingGlyph' → start element: no update
#fontA / 'glyph' → start element: no update
#fontA → end element: "A" rendered with fontA (represents current document state rendering)
#fontB → start element: no update
#fontB / 'font-face' → start element: no update
#fontB / 'missingGlyph' → start element: no update
#fontB / 'glyph' → start element: no update
#fontB → end element: "A" rendered with fontB (represents current document state rendering)
#fontC → start element: no update
#fontC / 'font-face' → start element: no update
#fontC / 'missingGlyph' → start element: no update
#fontC / 'glyph' → start element: no update
#fontC → end element: "A" rendered with fontC (represents current document state rendering)

5.9.3 The 'prefetch' element

SVG 1.1 did not specify when an SVG user agent should begin downloading referenced media. This lead to implementation differences particularly when the media was not used in the initial document state (e.g. it was offscreen or hidden). SVG Tiny 1.2 does not require SVG user agents to download referenced media that is not visible at the time the document is loaded, unless those media are contained inside a subtree for which 'externalResourcesRequired' is set to "true". This means there may be a pause to download the file the first time a piece of media is displayed. More advanced SVG user agents may wish to predict that particular media streams will be needed and therefore download them in anticipation.

SVG Tiny 1.2 therefore adds functionality to allow content developers to suggest prefetching content from the server before it is needed to improve the rendering performance of the document. The SMIL 2.1 'prefetch' element ([SMIL21], section 4.4) has been incorporated into SVG as the 'prefetch' element, with the following modifications:

Attributes cannot be given <percent-value> values.
The 'xlink:href' attribute is permitted to point into the document in which the 'prefetch' element appears so that this feature can be used as a hint indicating how much of the document is required before playback can start.
In order to adequately support non-local IRI references, the 'mediaCharacterEncoding' and 'mediaContentEncodings' attributes have been added.

The 'prefetch' element provides a hint to the SVG user agent that media will be used in the future and the author would like part or all of it fetched ahead of time to make document playback smoother. As it is a hint, user agents may ignore 'prefetch' elements, although doing so may cause an interruption in the document playback when the resource is needed. It gives authoring tools and authors the ability to schedule retrieval of resources when they think that there is available bandwidth or time to do it.

When instead of referring to external media, 'prefetch' refers to the same document it occurs in, then it can only reference a top level 'g' element. A top level 'g' element is a 'g' element that is a direct child of the rootmost 'svg' element.

To enable smooth playback during progressive downloading in this scenario, it is recommended that each adjacent top level 'g' element contains adjacent chronological scenes in the animation. In this case the 'prefetch' element must appear in a 'defs' block before all defined 'g' elements in the document. In such cases, 'prefetch' is used to tell the SVG user agent how much it needs to buffer in order to be able to play content back in a smooth and predictable manner.

Schema: prefetch

    <define name='prefetch'>
      <element name='prefetch'>
        <ref name='prefetch.AT'/>
        <ref name='prefetch.CM'/>
      </element>
    </define>

    <define name='prefetch.AT' combine='interleave'>
      <ref name='svg.Core.attr'/>
      <ref name='svg.XLinkRequired.attr'/>
      <optional>
        <attribute name='mediaSize' svg:animatable='false' svg:inheritable='false'>
          <ref name='Number.datatype'/>
        </attribute>
      </optional>
      <optional>
        <attribute name='mediaTime' svg:animatable='false' svg:inheritable='false'><text/></attribute>
      </optional>
      <optional>
        <attribute name='mediaCharacterEncoding' svg:animatable='false' svg:inheritable='false'><text/></attribute>
      </optional>
      <optional>
        <attribute name='mediaContentEncodings' svg:animatable='false' svg:inheritable='false'><text/></attribute>
      </optional>
      <optional>
        <attribute name='bandwidth' svg:animatable='false' svg:inheritable='false'>
          <choice>
            <ref name='Number.datatype'/>
            <value>auto</value>
          </choice>
        </attribute>
      </optional>
    </define>

    <define name='prefetch.CM'>
      <zeroOrMore>
        <ref name='svg.Desc.group'/>
      </zeroOrMore>
    </define>

Attribute definitions:

mediaSize = "<long>"

Defines how much of the media to fetch in bytes in terms of the file size of the media.

When 'prefetch' refers to a resource in the same document (i.e. a top level 'g' element), the 'mediaSize' attribute indicates the size in bytes of the 'g' element and its children. That size corresponds to the encodings used when transmitting the document. If the document is encoded in UTF-8 [RFC3629] and gzipped [RFC1952], then the size of the gzipped UTF-8 fragment applies. If that same document were decompressed and transcoded to UTF-16 [RFC2781] the hints will become stale. Since streaming hints are to be used primarily in streaming scenarios, it is not expected that hint staleness will occur frequently.

Animatable: no.

mediaTime = "<clock-value>"

Defines how much of the media to fetch in terms of the duration of the media. For discrete media (non-time based media such as PNG) using this attribute causes the entire resource to be prefetched.

When 'prefetch' refers to a resource in the same document (i.e. a top level 'g' element), this is the active duration of the referenced element. In cases where the exact active duration can not be calculated beforehand (e.g. if the end of an animation depends on user interaction), it is suggested that the content author estimate the minimum active duration for the referenced element. This estimate, even if zero, will allow the SVG user agent to calculate how much of the overall document to download before beginning playback in a streaming scenario.

Animatable: no.

bandwidth = "<long>"

Defines how much network bandwidth, in bits per second, the SVG user agent should use when performing the prefetch. If the attribute is not specified, all available bandwidth should be used.

Animatable: no.

mediaCharacterEncoding = "<string>"

Indicates the XML character set encoding (UTF-8, ISO-8859-1, etc.) that the 'mediaSize' attribute applies to. Tools that produce SVG should include this attribute if they specify the 'mediaSize' attribute. The main use of this attribute is to know what character encoding was used when measuring 'mediaSize' so that staleness of the hints may be easily detected. If the attribute is not specified, the encoding that was used to calculate the size is that which is returned by the server.

Animatable: no.

mediaContentEncodings = "<list-of-strings>"

The 'mediaContentEncodings' attribute is a white space separated list of the content encodings as defined in section 3.5 of HTTP/1.1 [RFC2616] (gzip, compress, etc.) that the 'mediaSize' attribute applies to. The order of the list is the order in which the content encodings were applied to encode the data. Note that while situations in which multiple content codings are applied are currently rare, they are allowed by HTTP/1.1 and thus that functionality is supported by SVG. Tools that produce SVG must include this attribute if they specify the 'mediaSize' attribute and the Content-Encoding is other than the identity encoding. The main use of this attribute is to know what parameters were used when measuring 'mediaSize' so that staleness of the hints may be easily detected. If the 'mediaContentEncodings' attribute is not specified it is as if the identity encoding value from HTTP/1.1 had been specified. This indicates that no transformation (i.e. encodings) at all has been used.

Animatable: no.

xlink:href = "<IRI>"

An IRI reference to the resource to prefetch. An invalid IRI reference is an unsupported value. An empty attribute value (xlink:href="") means that no prefetching will occur. The lacuna value is the empty string.

Animatable: no.

When 'prefetch' refers to external media, if both 'mediaSize' and 'mediaTime' are specified, then 'mediaSize' shall be used and 'mediaTime' is ignored. If neither 'mediaSize' nor 'mediaTime' is specified, the behavior is that the entire resource should be fetched.

When 'prefetch' refers to a resource in the same document (i.e. a top level 'g' element), both the 'mediaSize' and 'mediaTime' attributes can be used together by a more advanced SVG user agent to determine how much it needs to buffer in order to be able to play content back in a smooth manner.

Note that whereas the 'externalResourcesRequired' attribute is used to designate that a resource is required, the 'prefetch' element is used to optimize the retrieval of a resource. Setting the 'externalResourcesRequired' attribute does not influence the behavior of the 'prefetch' element and vice-versa. This is true whether the 'prefetch' element points to an internal 'g' element or external resource.

Example prefetch01 demonstrates the use of the 'prefetch' element when it refers to external media:

Example: prefetch01.svg

<svg width="400" height="300" version="1.2"
        xmlns="http://www.w3.org/2000/svg" baseProfile="tiny"
        xmlns:xlink="http://www.w3.org/1999/xlink">

     <desc>
        Prefetch the large images before starting the animation
        if possible.
     </desc>

     <defs>
       <prefetch xlink:href="http://www.example.com/images/huge1.png"/>
       <prefetch xlink:href="http://www.example.com/images/huge2.png"/>
       <prefetch xlink:href="http://www.example.com/images/huge3.png"/>
     </defs>

     <image x="0" y="0" width="400" height="300"
        xlink:href="http://www.example.com/images/huge1.png"
        display="none">

        <set attributeName="display" to="inline" begin="10s"/>
 
        <animate attributeName="xlink:href" values="
               http://www.example.com/images/huge1.png;
               http://www.example.com/images/huge2.png;
               http://www.example.com/images/huge3.png"
            begin="15s" dur="30s"/>
     </image>

   </svg>

Example prefetch02 is an example of the 'prefetch' element referring to a resource in the same document (i.e. a top level 'g' element):

Example: prefetch02.svg

<?xml version="1.0" encoding="utf-16"?>
<svg width="400" height="300" version="1.2"
        xmlns="http://www.w3.org/2000/svg" baseProfile="tiny"
        xmlns:xlink="http://www.w3.org/1999/xlink"
        timelineBegin="onStart"
        playbackOrder="forwardOnly">

     <desc>
        Example of using SVGT 1.2 features for smooth playback
        during progressive downloading.
     </desc>

     <defs>

       <prefetch xlink:href="#scene1"
                 mediaCharacterEncoding="UTF-16"
                 mediaTime="5s" mediaSize="94230" />

       <prefetch xlink:href="#scene2"
                 mediaCharacterEncoding="UTF-16"
                 mediaTime="10s" mediaSize="283474" />

       <prefetch xlink:href="#scene3"
                 mediaCharacterEncoding="UTF-16"
                 mediaTime="15s" mediaSize="627638" />

     </defs>

     <g xml:id="scene1">
       <discard begin="6s"/>
       <!-- graphics for scene 1 go here -->
     </g>

     <g xml:id="scene2">
       <discard begin="16s"/>
       <!-- graphics for scene 2 go here -->
     </g>

     <g xml:id="scene3">
       <discard begin="21s"/>
       <!-- graphics for scene 3 go here -->
     </g>

</svg>

5.10 Common attributes

5.10.1 Attributes common to all elements

The 'id', 'xml:id', 'xml:base', 'class', 'role', 'rel', 'rev', 'about', 'content', 'datatype', 'property', 'resource', and 'typeof' attributes are available on all elements defined by SVG Tiny 1.2. Some of these elements, such as 'id', 'xml:id', and 'xml:base' may have a direct effect on the structure and rendering of SVG, while others may only affect SVG indirectly, or may be used only for auxiliary processing of SVG content. See extensible metadata attributes for more details.

Attribute definitions:

id = "<NCName>"

This attribute specifies a unique identifier for the element. Because of wider use and compatibility with legacy content and existing user agents (including authoring tools), it is recommended that content intended for use in a Web browser environment use 'id' instead of 'xml:id'. (See details on ID attributes below.)

Animatable: no.

xml:id = "<NCName>"

This attribute specifies a unique identifier for the element. Refer to xml:id Version 1.0 [XMLID]. It is recommended that content intended for use with generic XML processing tools, particularly in a scenario where the datatype of the 'id' attribute is not known, use 'xml:id'. (See details on ID attributes below.)

Animatable: no.

xml:base = "<IRI>"

This attribute specifies a base IRI other than the base IRI of the document or external entity. Refer to XML Base [XML-BASE].

Animatable: no.

class = "<XML-NMTOKENS>"

The 'class' attribute assigns one or more class names to an element. The element may be said to belong to these classes. A class name may be shared by several element instances. The class attribute has several roles:

As a style sheet selector (when an author wishes to assign style information to a set of elements). Note: SVG Tiny 1.2 does not mandate the support of style sheets.
For general purpose processing by user agents.

The attribute value indicates membership in one or more sets. Any number of elements may be assigned to the same set. Multiple set names must be separated by white space characters.

Animatable: yes.

role = "<list-of-strings>"

The 'role' attribute assigns one or more role values to an element. The element may be said to have these roles. A role value may be shared by several element instances. Unlike the 'class' attribute, 'role' attribute values are intended to be selected from a predefined set of values with specific semantic aspects that are assigned to the element, such as those defined in the ARIA ontology [ARIA], XHTML Role Attribute Module [ROLE], XHTML Vocabulary collection [XHTMLVOCAB], and in future SVG specifications.

The 'role' attribute is intended to functionally align with the XHTML Role Attribute Module [ROLE].

The attribute value indicates membership in one or more sets. Any number of elements may be assigned to the same set. Multiple set names must be separated by white space characters.

Animatable: yes.

rel = "<list-of-strings>"

The 'rel' attribute assigns one or more relationship values to an element. The value of the 'rel' attribute expresses the relationships between two resources. For 'a' elements in particular, the 'rel' attribute indicates the relationship that the linked resource holds for the element's children or the element's containing document.

This attribute is an analog of the HTML [HTML4] attribute of the same name. It is intended to be used in the same manner, such as with RDFa [RDFA], Microformats [MF], and other semantic purposes.

The attribute value indicates membership in one or more sets. Any number of elements may be assigned to the same set. Multiple set names must be separated by white space characters.

Animatable: yes.

rev = "<list-of-strings>"

The 'rev' attribute assigns one or more relationship values to an element. The value of the 'rev' attribute expresses the reverse relationships between two resources. For 'a' elements in particular, the 'rev' attribute indicates the relationship that the element's children or the element's containing document holds for the linked resource.

This attribute is an analog of the HTML [HTML4] attribute of the same name. It is intended to be used in the same manner, such as with RDFa [RDFA], Microformats [MF], and other semantic purposes.

The attribute value indicates membership in one or more sets. Any number of elements may be assigned to the same set. Multiple set names must be separated by white space characters.

Animatable: yes.

about = "<list-of-strings>"

The 'about' attribute assigns one or more relationship values to an element. The value of the 'about' attribute is intended to be used for stating the subject of the element's data.

This attribute is intended to functionally align with the attribute of the same name in the RDFa [RDFA] specification, but is not limited to use with that format.

The attribute value indicates membership in one or more sets. Any number of elements may be assigned to the same set. Multiple set names must be separated by white space characters.

Animatable: yes.

content = "<string>"

The 'content' attribute provides a plain text value that may be suitable for humans, or may be machine-readable, or both, depending on the context. In general, this should only be used to supplement textual child content, or to be used on elements which do not normally take text as child content.

This attribute is intended to functionally align with the attribute of the same name in the RDFa [RDFA] specification, but is not limited to use with that format.

Animatable: yes.

datatype = "<string>"

The 'datatype' attribute specifies a semantic datatype for the content of the element, or the value of the 'content' attribute if one is provided for the element.

This attribute should not be confused with the 'type' attribute, and has no direct effect on the rendering or execution of the element.

This attribute is intended to functionally align with the attribute of the same name in the RDFa [RDFA] specification, but is not limited to use with that format.

Animatable: yes.

property = "<list-of-strings>"

The 'property' attribute is used for expressing relationships between the element's subject (e.g., the text content of a child node or of an attribute value) and a set of known or referenced properties.

This attribute is intended to functionally align with the attribute of the same name in the RDFa [RDFA] specification, but is not limited to use with that format.

The attribute value indicates membership in one or more sets. Any number of elements may be assigned to the same set. Multiple set names must be separated by white space characters.

Animatable: yes.

resource = "<string>"

The 'resource' attribute associates a resource, typically expressed with an IRI reference, to the element, in a manner that does not normally resolve the IRI reference.

This attribute is intended to functionally align with the attribute of the same name in the RDFa [RDFA] specification, but is not limited to use with that format.

Animatable: yes.

typeof = "<list-of-strings>"

The 'typeof' attribute associates one or more datatypes with the element. This attribute should not be confused with the 'type' attribute, and has no direct effect on the rendering or execution of the element.

This attribute is intended to functionally align with the attribute of the same name in the RDFa [RDFA] specification, but is not limited to use with that format.

The attribute value indicates membership in one or more sets. Any number of elements may be assigned to the same set. Multiple set names must be separated by white space characters.

Animatable: yes.

The 'id' and 'xml:id' attributes

Both the 'id' and 'xml:id' attributes specify a unique identifier for the element. Both are have the data type <NCName>, but are of type <ID> for purposes of validation. 'xml:id' is intended to represent type <ID> universally across all document types. This makes it more suitable for certain compound documents with arbitrary XML, or with generic XML toolchains which require explicit knowledge of <ID>-typed attributes.

It is strongly recommended that SVG generators only use 'id' to assign identity to elements, to maintain backwards compatibility with existing viewers, authoring tools, and other content.

There remains only one single id field on the SVGElement interface, which can be used to change the value of either attribute (e.g. by using the setAttributeNS(), setTraitNS(), or setTrait() methods). Likewise, the getElementById method on the Document interface applies equally to both the 'id' and 'xml:id' attributes.

Because they are intended for different environments, the 'id' and 'xml:id' attributes must not be used together on SVG elements in the same document. Such documents are not conforming SVG 1.2 Tiny content, and the behavior is not specified.

Transforming between 'id' and 'xml:id'

In order to facilitate the creation of content that can be used in both primary scenarios (that is, in existing desktop browsers and authoring tools, and in XML toolchains), an XSLT stylesheet can be used to convert the 'id' attributes to 'xml:id' attributes (and vice versa). For example, when content that has been authored with the browser environment in mind is being prepared for consumption by a generic XML tool, it can be preprocessed by using the id2xmlid.xsl sample stylesheet. This allows the same content to be used with little overhead or risk of breaking content. Example transformation stylesheets are provided below:

Example: id2xmlid.xsl

<xsl:stylesheet version="1.0"
                xmlns:xsl="http://www.w3.org/1999/XSL/Transform">

  <xsl:template match="node() | @*">
    <xsl:copy>
      <xsl:apply-templates select="node() | @*"/>
    </xsl:copy>
  </xsl:template>

  <xsl:template match="@id">
    <xsl:attribute name="xml:id">
      <xsl:value-of select="."/>
    </xsl:attribute>
  </xsl:template>

</xsl:stylesheet>

Example: xmlid2id.xsl

<xsl:stylesheet version="1.0"
                xmlns:xsl="http://www.w3.org/1999/XSL/Transform">

  <xsl:template match="node() | @*">
    <xsl:copy>
      <xsl:apply-templates select="node() | @*"/>
    </xsl:copy>
  </xsl:template>

  <xsl:template match="@xml:id">
    <xsl:attribute name="id">
      <xsl:value-of select="."/>
    </xsl:attribute>
  </xsl:template>

</xsl:stylesheet>

5.10.2 Attributes for character-content elements

Elements that might contain character data content have attributes 'xml:lang' and 'xml:space' to specify the natural language and whitespace processing of the content.

Schema: langspace

<attribute name='xml:space' svg:animatable='false' svg:inheritable='false'>
   <choice>
      <value>default</value>
      <value>preserve</value>
   </choice>
</attribute>

<attribute name='xml:lang' svg:animatable='false' svg:inheritable='false'>
  <choice>
     <ref name='LanguageCode.datatype'/>
     <empty/>
  </choice>
</attribute>

Attribute definitions:

xml:lang = "<language-id>"

This is a standard XML attribute used to specify the language (e.g., English) used in the child text content and attribute values of the element it occurs on. The value is either a language tag as defined in IETF BCP 47 [BCP 47] or the empty string, "". Refer to Extensible Markup Language (XML) 1.0 ([XML10], section 2.12) and Extensible Markup Language (XML) 1.1 ([XML11], section 2.12) for the definition of this attribute.

Animatable: no.

xml:space = "default" | "preserve"

This is a standard XML attribute used to specify whether white space is preserved in character data. The only possible values are "default" and "preserve". Refer to Extensible Markup Language (XML) 1.0 ([XML10], section 2.10) and Extensible Markup Language (XML) 1.1 ([XML11], section 2.10) for the definition of this attribute. See also the discussion of white space handling for text content elements in SVG.

Animatable: no.

7 Coordinate Systems, Transformations and Units

7.1 Introduction
7.2 The initial viewport
7.3 The initial coordinate system
7.4 Coordinate system transformations
7.5 Nested transformations
7.6 The 'transform' attribute
- 7.6.1 The TransformList value
7.7 Constrained transformations
- 7.7.1 The user transform
- 7.7.2 ViewBox to viewport transformation
- 7.7.3 Element transform stack
- 7.7.4 The current transformation matrix
- 7.7.5 The TransformRef value
7.8 The 'viewBox' attribute
7.9 The 'preserveAspectRatio' attribute
7.10 Establishing a new viewport
7.11 Units
7.12 Bounding box
7.13 Object bounding box units
7.14 Intrinsic sizing properties of the viewport of SVG content
7.15 Geographic coordinate systems
7.16 The 'svg:transform' attribute

7.1 Introduction

For all media, the canvas describes "the space where the SVG content is rendered." The canvas is infinite for each dimension of the space, but rendering occurs relative to a finite rectangular region of the canvas. This finite rectangular region is called the SVG viewport. For visual media ([CSS2], section 7.3.1), the SVG viewport is the viewing area where the user sees the SVG content.

The size of the SVG viewport (i.e., its width and height) is determined by a negotiation process (see Establishing the size of the initial viewport) between the SVG document fragment and its parent (real or implicit). Once the viewport is established, the SVG user agent must establish the initial viewport coordinate system and the initial user coordinate system (see Initial coordinate system). The viewport coordinate system is also called viewport space and the user coordinate system is also called user space.

A new user space (i.e., a new current coordinate system) can be established at any place within an SVG document fragment by specifying transformations in the form of transformation matrices or simple transformation operations such as rotation, skewing, scaling and translation (see Coordinate system transformations). Establishing new user spaces via coordinate system transformations are fundamental operations to 2D graphics and represent the usual method of controlling the size, position, rotation and skew of graphic objects.

New viewports also can be established. By establishing a new viewport, one can provide a new reference rectangle for "fitting" a graphic into a particular rectangular area. ("Fit" means that a given graphic is transformed in such a way that its bounding box in user space aligns exactly with the edges of a given viewport.)

7.2 The initial viewport

The SVG user agent negotiates with its parent user agent to determine the viewport into which the SVG user agent can render the document. In some circumstances, SVG content will be embedded (by reference or inline) within a containing document. This containing document might include attributes, properties and/or other parameters (explicit or implicit) which specify or provide hints about the dimensions of the viewport for the SVG content. SVG content itself optionally can provide information about the appropriate viewport region for the content via the 'width' and 'height' XML attributes on the 'svg' element. The negotiation process uses any information provided by the containing document and the SVG content itself to choose the viewport location and size.

If the parent document format defines rules for referenced or embedded graphics content, then the negotiation process is determined by the parent document format specification. If the parent document is styled with CSS, then the negotiation process must follow the CSS rules for replaced elements. If there are CSS width and height properties (or corresponding XSL properties) on the referencing element (or rootmost 'svg' element for inline SVG content) that are sufficient to establish the width and height of the viewport, then these positioning properties establish the viewport's width, height, and aspect ratio.

If there is no parent document, the SVG user agent must use the 'width' and 'height' attributes on the rootmost 'svg' element element as the width and height for the viewport.

Note that the time at which the viewport size negotiation is finalized is implementation-specific. Authors who need to be sure of the dimensions of the viewport should do so with load-event or resize-event handlers.

7.3 The initial coordinate system

For the 'svg' element, the SVG user agent must establish an initial viewport coordinate system and an initial user coordinate system such that the two coordinates systems are identical. The origin of both coordinate systems must be at the origin of the viewport, and one unit in the initial coordinate system must equal one "pixel" (i.e., a px unit as defined in CSS ([CSS2], section 4.3.2)) in the viewport. In most cases, such as stand-alone SVG documents or SVG document fragments embedded (by reference or inline) within XML parent documents where the parent's layout is determined by CSS [CSS2] or XSL [XSL], the SVG user agent must establish the initial viewport coordinate system (and therefore the initial user coordinate system) such that its origin is at the top/left of the viewport, with the positive x-axis pointing towards the right, the positive y-axis pointing down, and text rendered with an "upright" orientation, which means glyphs are oriented such that Roman characters and full-size ideographic characters for Asian scripts have the top edge of the corresponding glyphs oriented upwards and the right edge of the corresponding glyphs oriented to the right.

If the SVG implementation is part of a user agent which supports styling XML documents using CSS2-compatible px units, then the SVG user agent should get its initial value for the size of a px unit in real world units to match the value used for other XML styling operations; otherwise, if the user agent can determine the size of a px unit from its environment, it should use that value; otherwise, it should choose an appropriate size for one px unit. In all cases, the size of a px must be in conformance with the rules described in CSS ([CSS2], section 4.3.2).

Example 07_02 below shows that the initial coordinate system has the origin at the top/left with the x-axis pointing to the right and the y-axis pointing down. The initial user coordinate system has one user unit equal to the parent (implicit or explicit) user agent's "pixel".

Example: 07_02.svg

<?xml version="1.0"?>
<svg xmlns="http://www.w3.org/2000/svg" version="1.2" baseProfile="tiny"
     width="300px" height="100px">

  <desc>Example InitialCoords - SVG's initial coordinate system</desc>

  <g fill="none" stroke="black" stroke-width="3">
    <line x1="0" y1="1.5" x2="300" y2="1.5"/>
    <line x1="1.5" y1="0" x2="1.5" y2="100"/>
  </g>
  <g fill="red" stroke="none">
    <rect x="0" y="0" width="3" height="3"/>
    <rect x="297" y="0" width="3" height="3"/>
    <rect x="0" y="97" width="3" height="3"/>
  </g>
  <g font-size="14" font-family="Verdana">
    <text x="10" y="20">(0,0)</text>
    <text x="240" y="20">(300,0)</text>
    <text x="10" y="90">(0,100)</text>
  </g>
</svg>

7.4 Coordinate system transformations

A new user space (i.e., a new current coordinate system) can be established by specifying transformations in the form of a 'transform' attribute on a container or graphics element, or a 'viewBox' attribute on the 'svg' element. The 'transform' and 'viewBox' attributes transform user space coordinates and lengths on sibling attributes on the given element (see effect of the 'transform' attribute on sibling attributes and effect of the 'viewBox' attribute on sibling attributes) and all of its descendants. Transformations can be nested, in which case the effect of the transformations are cumulative.

Example 07_03 below shows a document without transformations. The text string is specified in the initial coordinate system.

Example: 07_03.svg

<?xml version="1.0"?>
<svg xmlns="http://www.w3.org/2000/svg" version="1.2" baseProfile="tiny"
     width="400px" height="150px">

  <desc>Example OrigCoordSys - Simple transformations: original picture</desc>

  <g fill="none" stroke="black" stroke-width="3">
    <!-- Draw the axes of the original coordinate system -->
    <line x1="0" y1="1.5" x2="400" y2="1.5"/>
    <line x1="1.5" y1="0" x2="1.5" y2="150"/>
  </g>
  <g>
    <text x="30" y="30" font-size="20" font-family="Verdana">
      ABC (orig coord system)
    </text>
  </g>
</svg>

Example 07_04 establishes a new user coordinate system by specifying transform="translate(50,50)" on the third 'g' element below. The new user coordinate system has its origin at location (50,50) in the original coordinate system. The result of this transformation is that the coordinate (30,30) in the new user coordinate system gets mapped to coordinate (80,80) in the original coordinate system (i.e., the coordinates have been translated by 50 units in x and 50 units in y).

Example: 07_04.svg

<?xml version="1.0"?>
<svg xmlns="http://www.w3.org/2000/svg" version="1.2" baseProfile="tiny"
     width="400px" height="150px">

  <desc>Example NewCoordSys - New user coordinate system</desc>

  <g fill="none" stroke="black" stroke-width="3">
    <!-- Draw the axes of the original coordinate system -->
    <line x1="0" y1="1.5" x2="400" y2="1.5"/>
    <line x1="1.5" y1="0" x2="1.5" y2="150"/>
  </g>
  <g>
    <text x="30" y="30" font-size="20" font-family="Verdana">
      ABC (orig coord system)
    </text>
  </g>
  <!-- Establish a new coordinate system, which is
       shifted (i.e., translated) from the initial coordinate
       system by 50 user units along each axis. -->
  <g transform="translate(50,50)">
    <g fill="none" stroke="red" stroke-width="3">
      <!-- Draw lines of length 50 user units along 
           the axes of the new coordinate system -->
      <line x1="0" y1="0" x2="50" y2="0" stroke="red"/>
      <line x1="0" y1="0" x2="0" y2="50"/>
    </g>
    <text x="30" y="30" font-size="20" font-family="Verdana">
      ABC (translated coord system)
    </text>
  </g>
</svg>

Example 07_05 illustrates simple rotate and scale transformations. The example defines two new coordinate systems:

one which is the result of a translation by 50 units in x and 30 units in y, followed by a rotation of 30 degrees
another which is the result of a translation by 200 units in x and 40 units in y, followed by a scale transformation of 1.5.

Example: 07_05.svg

<?xml version="1.0"?>
<svg xmlns="http://www.w3.org/2000/svg" version="1.2" baseProfile="tiny"
     width="400px" height="120px">

  <desc>Example RotateScale - Rotate and scale transforms</desc>

  <g fill="none" stroke="black" stroke-width="3">
    <!-- Draw the axes of the original coordinate system -->
    <line x1="0" y1="1.5" x2="400" y2="1.5"/>
    <line x1="1.5" y1="0" x2="1.5" y2="120"/>
  </g>
  <!-- Establish a new coordinate system whose origin is at (50,30)
       in the initial coord. system and which is rotated by 30 degrees. -->
  <g transform="translate(50,30)">
    <g transform="rotate(30)">
      <g fill="none" stroke="red" stroke-width="3">
        <line x1="0" y1="0" x2="50" y2="0"/>
        <line x1="0" y1="0" x2="0" y2="50"/>
      </g>
      <text x="0" y="0" font-size="20" font-family="Verdana" fill="blue">
        ABC (rotate)
      </text>
    </g>
  </g>
  <!-- Establish a new coordinate system whose origin is at (200,40)
       in the initial coord. system and which is scaled by 1.5. -->
  <g transform="translate(200,40)">
    <g transform="scale(1.5)">
      <g fill="none" stroke="red" stroke-width="3">
        <line x1="0" y1="0" x2="50" y2="0"/>
        <line x1="0" y1="0" x2="0" y2="50"/>
      </g>
      <text x="0" y="0" font-size="20" font-family="Verdana" fill="blue">
        ABC (scale)
      </text>
    </g>
  </g>
</svg>

Example 07_06 defines two coordinate systems which are skewed relative to the origin coordinate system.

Example: 07_06.svg

<?xml version="1.0"?>
<svg xmlns="http://www.w3.org/2000/svg" version="1.2" baseProfile="tiny"
     width="400px" height="120px">

  <desc>Example Skew - Show effects of skewX and skewY</desc>

  <g fill="none" stroke="black" stroke-width="3">
    <!-- Draw the axes of the original coordinate system -->
    <line x1="0" y1="1.5" x2="400" y2="1.5"/>
    <line x1="1.5" y1="0" x2="1.5" y2="120"/>
  </g>
  <!-- Establish a new coordinate system whose origin is at (30,30)
       in the initial coord. system and which is skewed in X by 30 degrees. -->
  <g transform="translate(30,30)">
    <g transform="skewX(30)">
      <g fill="none" stroke="red" stroke-width="3">
        <line x1="0" y1="0" x2="50" y2="0"/>
        <line x1="0" y1="0" x2="0" y2="50"/>
      </g>
      <text x="0" y="0" font-size="20" font-family="Verdana" fill="blue">
        ABC (skewX)
      </text>
    </g>
  </g>
  <!-- Establish a new coordinate system whose origin is at (200,30)
       in the initial coord. system and which is skewed in Y by 30 degrees. -->
  <g transform="translate(200,30)">
    <g transform="skewY(30)">
      <g fill="none" stroke="red" stroke-width="3">
        <line x1="0" y1="0" x2="50" y2="0"/>
        <line x1="0" y1="0" x2="0" y2="50"/>
      </g>
      <text x="0" y="0" font-size="20" font-family="Verdana" fill="blue">
        ABC (skewY)
      </text>
    </g>
  </g>
</svg>

Mathematically, all transformations can be represented as 3x3 transformation matrices of the following form:

Since only six values are used in the above 3x3 matrix, a transformation matrix is also expressed as a vector: [a b c d e f].

Transformations map coordinates and lengths from a new coordinate system into a previous coordinate system:

Simple transformations are represented in matrix form as follows:

Translation is equivalent to the matrix:

or [1 0 0 1 tx ty], where tx and ty are the distances to translate coordinates in x and y, respectively.
Scaling is equivalent to the matrix:

or [sx 0 0 sy 0 0]. One unit in the x and y directions in the new coordinate system equals sx and sy units in the previous coordinate system, respectively.
Rotation about the origin is equivalent to the matrix:

or [cos(a) sin(a) -sin(a) cos(a) 0 0], which has the effect of rotating the coordinate system axes by angle a.
A skew transformation along the x-axis is equivalent to the matrix:

or [1 0 tan(a) 1 0 0], which has the effect of skewing x coordinates by angle a.
A skew transformation along the y-axis is equivalent to the matrix:

or [1 tan(a) 0 1 0 0], which has the effect of skewing y coordinates by angle a.

7.5 Nested transformations

Transformations can be nested to any level. The effect of nested transformations is to post-multiply (i.e., concatenate) the subsequent transformation matrices onto previously defined transformations:

For each given element, the accumulation of all transformations that have been defined on the given element and all of its ancestors up to and including the element that established the current viewport (usually, the 'svg' element which is the most immediate ancestor to the given element) is called the current transformation matrix or CTM. The CTM thus represents the mapping of current user coordinates to viewport coordinates:

Example 07_07 illustrates nested transformations.

Example: 07_07.svg

<?xml version="1.0"?>
<svg width="400px" height="150px" version="1.2" baseProfile="tiny"
     xmlns="http://www.w3.org/2000/svg">
  <desc>Example Nested - Nested transformations</desc>
  <g fill="none" stroke="black" stroke-width="3" >
    <!-- Draw the axes of the original coordinate system -->
    <line x1="0" y1="1.5" x2="400" y2="1.5" />
    <line x1="1.5" y1="0" x2="1.5" y2="150" />
  </g>
  <!-- First, a translate -->
  <g transform="translate(50,90)">
    <g fill="none" stroke="red" stroke-width="3" >
      <line x1="0" y1="0" x2="50" y2="0" />
      <line x1="0" y1="0" x2="0" y2="50" />
    </g>
    <text x="0" y="0" font-size="16" font-family="Verdana" >
      ....Translate(1)
    </text>
    <!-- Second, a rotate -->
    <g transform="rotate(-45)">
      <g fill="none" stroke="green" stroke-width="3" >
        <line x1="0" y1="0" x2="50" y2="0" />
        <line x1="0" y1="0" x2="0" y2="50" />
      </g>
      <text x="0" y="0" font-size="16" font-family="Verdana" >
        ....Rotate(2)
      </text>
      <!-- Third, another translate -->
      <g transform="translate(130,160)">
        <g fill="none" stroke="blue" stroke-width="3" >
          <line x1="0" y1="0" x2="50" y2="0" />
          <line x1="0" y1="0" x2="0" y2="50" />
        </g>
        <text x="0" y="0" font-size="16" font-family="Verdana" >
          ....Translate(3)
        </text>
      </g>
    </g>
  </g>
</svg>

In the example above, the CTM within the third nested transformation (i.e., the transform="translate(130,160)") consists of the concatenation of the three transformations, as follows:

7.6 The 'transform' attribute

Attribute definition:

transform = "<transform-list>" | "<transform-ref>" | "none"

This attribute specifies a coordinate system transformation to apply to the element it appears on. The value of this attribute takes one of three forms:

<transform-list>: Specifies a list of affine transformations. See the definition in The TransformList value section below for details.
<transform-ref>: Specifies a constrained transformation. See the definition in The TransformRef value section below for details.
none: Specifies the identity transformation. Using this value has the same effect on the element's CTM as using the identity matrix (transform="matrix(1 0 0 1 0 0)") or not specifying the 'transform' attribute at all. This is the lacuna value.

Animatable: yes.

If the 'transform' attribute cannot be parsed according to the syntaxes above, then it has an unsupported value. In this case, as with any instance of an unsupported value, the SVG user agent must process the element as if the 'transform' attribute had not been specified, which will result in the element's transformation being the identity transformation.

7.6.1 The TransformList value

A <transform-list> is defined as a list of transform definitions, which are applied in the order provided. The individual transform definitions are separated by white space and/or a comma. The available types of transform definitions are as follows:

matrix(<a> <b> <c> <d> <e> <f>), which specifies a transformation in the form of a transformation matrix of six values. matrix(a,b,c,d,e,f) is equivalent to applying the transformation matrix [a b c d e f].
translate(<tx> [<ty>]), which specifies a translation by tx and ty. If <ty> is not provided, it is assumed to be zero.
scale(<sx> [<sy>]), which specifies a scale operation by sx and sy. If <sy> is not provided, it is assumed to be equal to <sx>.
rotate(<rotate-angle> [<cx> <cy>]), which specifies a rotation by <rotate-angle> degrees about a given point.

If optional parameters <cx> and <cy> are not supplied, the rotation is about the origin of the current user coordinate system. The operation corresponds to the matrix [cos(a) sin(a) -sin(a) cos(a) 0 0].

If optional parameters <cx> and <cy> are supplied, the rotation is about the point (cx, cy). The operation represents the equivalent of the following specification: translate(<cx>, <cy>) rotate(<rotate-angle>) translate(-<cx>, -<cy>).
skewX(<skew-angle>), which specifies a skew transformation along the x-axis.
skewY(<skew-angle>), which specifies a skew transformation along the y-axis.

All numeric values are real <number>s.

If the list of transforms includes a matrix with all values set to zero (that is, 'matrix(0,0,0,0,0,0)'), then rendering of the element is disabled. Such a value is not an unsupported value.

If a list of transforms includes more than one transform definition, then the net effect is as if each transform had been specified separately in the order provided. For example,

Example: 07_08.svg

<g transform="translate(-10,-20) scale(2) rotate(45) translate(5,10)">
  <!-- graphics elements go here -->
</g>

will have the same rendering as:

Example: 07_09.svg

<g transform="translate(-10,-20)">
  <g transform="scale(2)">
    <g transform="rotate(45)">
      <g transform="translate(5,10)">
        <!-- graphics elements go here -->
      </g>
    </g>
  </g>
</g>

The 'transform' attribute is applied to an element before processing any other coordinate or length values supplied for that element. In the element

Example: 07_10.svg

<rect x="10" y="10" width="20" height="20" transform="scale(2)"/>

the 'x', 'y', 'width' and 'height', values are processed after the current coordinate system has been scaled uniformly by a factor of 2 by the 'transform' attribute. Attributes 'x', 'y', 'width' and 'height' (and any other attributes or properties) are treated as values in the new user coordinate system, not the previous user coordinate system. Thus, the above 'rect' element is functionally equivalent to:

Example: 07_11.svg

<g transform="scale(2)">
  <rect x="10" y="10" width="20" height="20"/>
</g>

The following is an EBNF grammar for <transform-list> values [EBNF]:

transform-list ::=
    wsp* transforms? wsp*
transforms ::=
    transform
    | transform comma-wsp+ transforms
transform ::=
    matrix
    | translate
    | scale
    | rotate
    | skewX
    | skewY
matrix ::=
    "matrix" wsp* "(" wsp*
       number comma-wsp
       number comma-wsp
       number comma-wsp
       number comma-wsp
       number comma-wsp
       number wsp* ")"
translate ::=
    "translate" wsp* "(" wsp* number ( comma-wsp number )? wsp* ")"
scale ::=
    "scale" wsp* "(" wsp* number ( comma-wsp number )? wsp* ")"
rotate ::=
    "rotate" wsp* "(" wsp* number ( comma-wsp number comma-wsp number )? wsp* ")"
skewX ::=
    "skewX" wsp* "(" wsp* number wsp* ")"
skewY ::=
    "skewY" wsp* "(" wsp* number wsp* ")"
number ::=
    sign? integer-constant
    | sign? floating-point-constant
comma-wsp ::=
    (wsp+ comma? wsp*) | (comma wsp*)
comma ::=
    ","
integer-constant ::=
    digit-sequence
floating-point-constant ::=
    fractional-constant exponent?
    | digit-sequence exponent
fractional-constant ::=
    digit-sequence? "." digit-sequence
    | digit-sequence "."
exponent ::=
    ( "e" | "E" ) sign? digit-sequence
sign ::=
    "+" | "-"
digit-sequence ::=
    digit
    | digit digit-sequence
digit ::=
    "0" | "1" | "2" | "3" | "4" | "5" | "6" | "7" | "8" | "9"
wsp ::=
    (#x20 | #x9 | #xD | #xA)

7.7 Constrained transformations

SVG 1.2 extends the coordinate system transformations allowed on container elements and graphics element to provide a method by which graphical objects can remain fixed in the viewport without being scaled or rotated. Use cases include thin lines that do not become fatter on zooming in, map symbols or icons of a constant size, and so forth.

The following summarizes the different transforms that are applied to a graphical object as it is rendered.

7.7.1 The user transform

The user transform is the transformation that the SVG user agent positioning controls apply to the viewport coordinate system. This transform can be considered to be applied to a group that surrounds the 'svg' element of the document.

The SVG user agent positioning controls consist of a translation (commonly referred to as the "pan"), a scale (commonly referred to as the "zoom") and a rotate.

US = Matrix corresponding to the user scale  (currentScale on SVGSVGElement)
UP = Matrix corresponding to the user pan    (currentTranslate on SVGSVGElement)
UR = Matrix corresponding to the user rotate (currentRotate on SVGSVGElement)

The user transform is the product of these component transformations.

U = User transform
  = UP . US . UR

7.7.2 ViewBox to viewport transformation

Some SVG elements, such as the rootmost 'svg' element, create their own viewport. The 'viewBox' to viewport transformation is the transformation on an 'svg' element that adjusts the coordinate system to take the 'viewBox' and 'preserveAspectRatio' attributes into account.

We use the following notation for a 'viewBox' to viewport transformation:

VB(svgId)

The svgId parameter is the value of the 'id' or 'xml:id' attribute on a given 'svg' element.

7.7.3 Element transform stack

All elements in an SVG document have a transform stack. This is the list of transforms that manipulate the coordinate system between the element and its nearest ancestor 'svg' element, i.e. in this specification, the root element.

We use the following notation for the element transform stack on a given element:

TS(id)

The id parameter is the value of the 'id' or 'xml:id' attribute on a given element.

Similarly, we use the following notation for the transform defined by the 'transform' attribute on the given element with identifier id:

Txf(id)

With the above definition, the transformation TS of an element is equal to the product of all the transformations Txf from that element to its nearest ancestor 'svg'.

TS(id) = Txf(id.nearestViewportElement) . [...] . Txf(id.parentElement) . Txf(id)

Example: Element transform stack

<svg xml:id="root" version="1.2" baseProfile="tiny">
  <g xml:id="g" transform="scale(2)">
    <rect xml:id="r" transform="scale(4)"/>
    <g xml:id="g2">
      <rect xml:id="r2" transform="scale(0.5)"/>
    </g>
  </g>
</svg>

In this example, the transforms are:

TS(g)  = scale(2)
TS(r)  = TS(g) . scale(4)   = scale(8)
TS(g2) = TS(g) . I          = scale(2)   (where I is the identity matrix)
TS(r2) = TS(g) . scale(0.5) = scale(1)

7.7.4 The current transformation matrix

Each element in the rendering tree has the concept of a current transformation matrix or CTM. This is the product of all coordinate system transformations that apply to an element, effectively mapping the element into a coordinate system that is then transformed into device units by the SVG user agent.

Consider the following example, with a rectangle having a set of ancestor 'g' elements with IDs "g-0" to "g-n".

Example: Current transformation matrix

<svg xml:id="root" version="1.2" baseProfile="tiny">
  ...
  <g xml:id="g-n">
    ...
    <g xml:id="g-2">
      ...
      <g xml:id="g-1">
        ...
        <g xml:id="g-0">
          ...
          <rect xml:id="elt" .../>
        </g>
      </g>
    </g>
  </g>
</svg>

With the above definitions for U, VB, and TS, the CTM for the rectangle with xml:id="elt" is computed as follows:

CTM(elt) = U . VB(root) . TS(elt)
         = U . VB(root) . Txf(g-n) . [...] . Txf(g-0) . Txf(elt)

Example: Current transformation matrix, n=2

<svg xml:id="root" version="1.2" baseProfile="tiny">
  ...
  <g xml:id="g-1">
    ...
    <g xml:id="g-0">
      ...
      <rect xml:id="elt" .../>
    </g>
  </g>
</svg>

This produces the following transformations:

CTM(elt) = U . VB(root) . Txf(g-1) . Txf(g-0) . Txf(elt)

Note the important relationship between an element's CTM and its parent CTM, for elements which do not define a viewport:

CTM(elt) = CTM(elt.parentElement) . Txf(elt)

7.7.5 The TransformRef value

By using the 'ref(...)' attribute value on the 'transform' attribute it is possible to specify simple constrained transformations.

The 'ref(svg, x, y)' transform evaluates to the inverse of the element's parent's CTM multiplied by the rootmost 'svg' element's CTM but exclusive of that 'svg' element's zoom/pan/rotate user transform, if any.

Note that the inverse of the parent element's CTM may not always exist. In such cases, the user agent can instead calculate the CTM of the element with the constrained transformation by looking up the CTM of the rootmost 'svg' element directly. The 'ref(...)' value in this case is not an unsupported value.

The x and y parameters are optional. If they are specified, an additional translation is appended to the transform so that (0, 0) in the element's user space maps to (x, y) in the 'svg' element's user space. If no x and y parameters are specified, no additional translation is applied.

Using the definitions provided above, and using "svg[0]" to denote the rootmost 'svg' element:

Inverse of the parent's CTM: inv(CTM(elt.parentElement))

The svg element's user transform, exclusive of zoom,
pan and rotate transforms:
CTM(svg[0].parentElement) . VB(svg[0])

CTM(svg[0].parentElement) evaluates to Identity since there
is no svg[0].parentElement element.

In addition, the T(x, y) translation is such that:

CTM(elt) . (0, 0) = CTM(svg[0]) . (x, y)

So the transform evaluates to:

Txf(elt) = inv(CTM(elt.parentElement)) . CTM(svg[0].parentElement) . VB(svg[0]) . T(x, y)

Thus, the element's CTM is:

CTM(elt) = CTM(elt.parentElement) . Txf(elt)
         = CTM(svg[0].parentElement) . VB(svg[0]) . T(x,y)

Example: ref() transform
A small rectangle initially marks the middle of a line. The SVG user agent viewport is a square with sides of 200 units.

<svg xml:id="root" version="1.2" baseProfile="tiny" viewBox="0 0 100 100">
  <line x1="0" x2="100" y1="0" y2="100"/>
  <rect xml:id="r" transform="ref(svg)"
        x="45" y="45" width="10" height="10"/>
</svg>

In this case:

Txf(r) = inv(CTM(r.parent)) . CTM(root.parentElement) . VB(root) . T(x, y)

CTM(root.parentElement) evaluates to Identity.

T(x, y) evaluates to Identity because (x, y) is not specified

CTM(r) = CTM(r.parent) . Txf(r)
       = CTM(r.parent) . inv(CTM(r.parent)) . VB(root)
       = VB(root)
       = scale(2)

Consequently, regardless of the user transform (due to currentTranslate, currentScale and currentRotate) the rectangle's coordinates in viewport space will always be: (45, 45, 10, 10) * scale(2) = (90, 90, 20, 20). Initially, the line is from (0, 0) to (200, 200) in the viewport coordinate system. If we apply a user agent zoom of 3 (currentScale = 3), the rectangle is still (90, 90, 20, 20) but the line is (0, 0, 600, 600) and the marker no longer marks the middle of the line.

Example: ref() transform
A small rectangle always marks the middle of a line. Again, the SVG user agent viewport is a square with sides of 200 units.

<svg xml:id="root" version="1.2" baseProfile="tiny" viewBox="0 0 100 100"> 
  <line x1="0" x2="100" y1="0" y2="100"/>
  <g xml:id="g" transform="ref(svg, 50, 50)">
    <rect xml:id="r" x="-5" y="-5" width="10" height="10"/>
  </g>
</svg>

In this case:

Txf(g) = inv(CTM(g.parent)) . CTM(root.parentElement) . VB(root) . T(x,y)

CTM(root.parentElement) evaluates to Identity.

CTM(g) = CTM(g.parent) . Txf(r)
       = CTM(g.parent) . inv(CTM(g.parent)) . VB(root) . T(x,y)
       = VB(root) . T(x,y)
       = scale(2) . T(x,y)

Initially, (50, 50) in the 'svg' user space is (100, 100) in viewport space. Therefore:

CTM(g) . [0, 0] = CTM(root) . [50, 50]
                = scale(2) . [50, 50]
                = [100, 100]

and

scale(2) . T(x,y) = [100, 100]

T(x,y) = translate(50, 50)

If the SVG user agent pan was (50, 80) (modifying currentTranslate) then we now have (50, 50) in the 'svg' element's user space located at (150, 180) in viewport space. This produces:

CTM(g) . [0, 0] = CTM(root) . [50, 50]
                = translate(50, 80) . scale(2) . [50, 50]
                = [150, 180]

and

scale(2) . T(x,y) = [150, 180]

T(x, y) = translate(75, 90)

Therefore, regardless of the user transform, the rectangle will always overlap the middle of the line. Note that the rectangle will not rotate with the line (e.g., if currentRotate is set) and it will not scale either.

The following is an EBNF grammar for <transform-ref> values [EBNF]:

transform-ref ::=
    wsp* ref wsp*
ref ::=
    "ref" wsp* "(" wsp* "svg" wsp* ")"
    | "ref" wsp* "(" wsp* "svg" comma-wsp number comma-wsp number wsp* ")"
number ::=
    sign? integer-constant
    | sign? floating-point-constant
comma-wsp ::=
    (wsp+ comma? wsp*) | (comma wsp*)
comma ::=
    ","
integer-constant ::=
    digit-sequence
floating-point-constant ::=
    fractional-constant exponent?
    | digit-sequence exponent
fractional-constant ::=
    digit-sequence? "." digit-sequence
    | digit-sequence "."
exponent ::=
    ( "e" | "E" ) sign? digit-sequence
sign ::=
    "+" | "-"
digit-sequence ::=
    digit
    | digit digit-sequence
digit ::=
    "0" | "1" | "2" | "3" | "4" | "5" | "6" | "7" | "8" | "9"
wsp ::=
    (#x20 | #x9 | #xD | #xA)

7.8 The 'viewBox' attribute

It is often desirable to specify that a given set of graphics stretch to fit a particular container element. The 'viewBox' attribute provides this capability. All elements that establish a new viewport (see elements that establish viewports) can have the 'viewBox' attribute specified on them.

Attribute definition:

viewBox = "<list-of-numbers>" | "none"

Specifies a rectangular region into which child graphical content must be fit. The value of this attribute takes one of two forms:

<list-of-numbers>: A list of four <number>s (<min-x>, <min-y>, <width> and <height>), separated by white space and/or a comma, which specify a rectangle in viewport space which must be mapped to the bounds of the viewport established by the given element, taking into account the 'preserveAspectRatio' attribute. If specified, an additional transformation is applied to all descendants of the given element to achieve the specified effect.
none: Specifying a value of "none" indicates that a supplemental transformation due to the 'viewBox' attribute must not be used. Using this value will have the same affect on child content as not specifying the 'viewBox' attribute at all. This is the lacuna value.

Animatable: yes.

A negative value for <width> or <height> is unsupported. A value of zero for either of these two parameters disables rendering of the element.

Example 07_12 illustrates the use of the 'viewBox' attribute on the 'svg' element to specify that the SVG content must stretch to fit the bounds of the viewport.

Example: 07_12.svg

<?xml version="1.0"?>
<svg xmlns="http://www.w3.org/2000/svg" version="1.2" baseProfile="tiny"
     width="300px" height="200px" viewBox="0 0 1500 1000"
     preserveAspectRatio="none">

  <desc>
    Example ViewBox - uses the viewBox attribute to automatically create an
    initial user coordinate system which causes the graphic to scale to fit
    into the viewport no matter what size the viewport is.
  </desc>

  <!-- This rectangle goes from (0,0) to (1500,1000) in user space.
       Because of the viewBox attribute above,
       the rectangle will end up filling the entire area
       reserved for the SVG content. -->
  <rect x="0" y="0" width="1500" height="1000" 
        fill="yellow" stroke="blue" stroke-width="12"/>

  <!-- A large, red triangle -->
  <path fill="red"  d="M 750,100 L 250,900 L 1250,900 z"/>

  <!-- A text string that spans most of the viewport -->
  <text x="100" y="600" font-size="200" font-family="Verdana">
    Stretch to fit
  </text>
</svg>

Rendered into viewport with width=300px, height=200px		width=150px, height=200px

The effect of the 'viewBox' attribute is that the SVG user agent automatically supplies the appropriate transformation matrix to map the specified rectangle in user space to the bounds of a designated region (often, the viewport). To achieve the effect of the example on the left, with viewport dimensions of 300 by 200 pixels, the SVG user agent needs to automatically insert a transformation which scales both x and y by 0.2. The effect is equivalent to having a viewport of size 300px by 200px and the following supplemental transformation in the document, as follows:

<svg xmlns="http://www.w3.org/2000/svg" version="1.2" baseProfile="tiny"
     width="300px" height="200px">
  <g transform="scale(0.2)">
    <!-- Rest of document goes here -->
  </g>
</svg>

To achieve the effect of the example on the right, with viewport dimensions of 150 by 200 pixels, the SVG user agent needs to automatically insert a transformation which scales x by 0.1 and y by 0.2. The effect is equivalent to having a viewport of size 150px by 200px and the following supplemental transformation in the document, as follows:

<svg xmlns="http://www.w3.org/2000/svg" version="1.2" baseProfile="tiny"
     width="150px" height="200px">
  <g transform="scale(0.1 0.2)">
    <!-- Rest of document goes here -->
  </g>
</svg>

(Note: in some cases the SVG user agent will need to supply a translate transformation in addition to a scale transformation. For example, on an 'svg' element, a translate transformation will be needed if the 'viewBox' attribute specifies values other than zero for <min-x> or <min-y>.)

Unlike the 'transform' attribute (see effect of the 'transform' attribute on sibling attributes), the automatic transformation that is created due to a 'viewBox' does not affect the 'x', 'y', 'width' and 'height' attributes on the element with the 'viewBox' attribute. Thus, in the example above which shows an 'svg' element which has attributes 'width', 'height' and 'viewBox', the 'width' and 'height' attributes represent values in the coordinate system that exists before the 'viewBox' transformation is applied. On the other hand, like the 'transform' attribute, it does establish a new coordinate system for all other attributes and for descendant elements.

The following is an EBNF grammar for values of the 'viewBox' attribute [EBNF]:

viewbox ::=
    wsp* viewboxSpec wsp*
viewboxSpec ::=
    number comma-wsp number comma-wsp number comma-wsp number
    | "none"
number ::=
    sign? integer-constant
    | sign? floating-point-constant
comma-wsp ::=
    (wsp+ comma? wsp*) | (comma wsp*)
comma ::=
    ","
integer-constant ::=
    digit-sequence
floating-point-constant ::=
    fractional-constant exponent?
    | digit-sequence exponent
fractional-constant ::=
    digit-sequence? "." digit-sequence
    | digit-sequence "."
exponent ::=
    ( "e" | "E" ) sign? digit-sequence
sign ::=
    "+" | "-"
digit-sequence ::=
    digit
    | digit digit-sequence
digit ::=
    "0" | "1" | "2" | "3" | "4" | "5" | "6" | "7" | "8" | "9"
wsp ::=
    (#x20 | #x9 | #xD | #xA)

7.9 The 'preserveAspectRatio' attribute

In some cases, typically when using the 'viewBox' attribute, it is desirable that the graphics stretch to fit non-uniformly to take up the entire viewport. In other cases, it is desirable that uniform scaling be used for the purposes of preserving the aspect ratio of the graphics.

'preserveAspectRatio' is available for all elements that establish a new viewport (see elements that establish viewports), indicates whether or not to force uniform scaling.

'preserveAspectRatio' only applies when a value has been provided for 'viewBox' on the same element. Or, in some cases, if an implicit 'viewBox' value can be established for the element (see each element description for details on this). If a 'viewBox' value can not be determined then 'preserveAspectRatio' is ignored.

Attribute definition:

preserveAspectRatio = ["defer"] <align> [<meet>]

defer

If the value of 'preserveAspectRatio' on an element that references data ('image', 'animation' and 'video') starts with defer then the value of the 'preserveAspectRatio' attribute on the referenced content if present must be used. If the referenced content lacks a value for 'preserveAspectRatio' then the 'preserveAspectRatio' attribute must be processed as normal (ignoring defer). For 'preserveAspectRatio' on all other elements the defer portion of the attribute is ignored.

<align>

Indicates whether to force uniform scaling and, if so, the alignment method to use in case the aspect ratio of the 'viewBox' doesn't match the aspect ratio of the viewport. The <align> parameter must be one of the following strings:

none - Do not force uniform scaling. Scale the graphic content of the given element non-uniformly if necessary such that the element's bounding box exactly matches the viewport rectangle.
xMinYMin - Force uniform scaling.
Align the <min-x> of the element's 'viewBox' with the smallest X value of the viewport.
Align the <min-y> of the element's 'viewBox' with the smallest Y value of the viewport.
xMidYMin - Force uniform scaling.
Align the midpoint X value of the element's 'viewBox' with the midpoint X value of the viewport.
Align the <min-y> of the element's 'viewBox' with the smallest Y value of the viewport.
xMaxYMin - Force uniform scaling.
Align the <min-x>+<width> of the element's 'viewBox' with the maximum X value of the viewport.
Align the <min-y> of the element's 'viewBox' with the smallest Y value of the viewport.
xMinYMid - Force uniform scaling.
Align the <min-x> of the element's 'viewBox' with the smallest X value of the viewport.
Align the midpoint Y value of the element's 'viewBox' with the midpoint Y value of the viewport.
xMidYMid (the lacuna value) - Force uniform scaling.
Align the midpoint X value of the element's 'viewBox' with the midpoint X value of the viewport.
Align the midpoint Y value of the element's 'viewBox' with the midpoint Y value of the viewport.
xMaxYMid - Force uniform scaling.
Align the <min-x>+<width> of the element's 'viewBox' with the maximum X value of the viewport.
Align the midpoint Y value of the element's 'viewBox' with the midpoint Y value of the viewport.
xMinYMax - Force uniform scaling.
Align the <min-x> of the element's 'viewBox' with the smallest X value of the viewport.
Align the <min-y>+<height> of the element's 'viewBox' with the maximum Y value of the viewport.
xMidYMax - Force uniform scaling.
Align the midpoint X value of the element's 'viewBox' with the midpoint X value of the viewport.
Align the <min-y>+<height> of the element's 'viewBox' with the maximum Y value of the viewport.
xMaxYMax - Force uniform scaling.
Align the <min-x>+<width> of the element's 'viewBox' with the maximum X value of the viewport.
Align the <min-y>+<height> of the element's 'viewBox' with the maximum Y value of the viewport.

<meet>

Optional and only available due to historical reasons. The <meet> is separated from the <align> value by one or more spaces and must equal the string meet.

meet indicates to scale the graphic such that:

aspect ratio is preserved
the entire 'viewBox' is visible within the viewport
the 'viewBox' is scaled up as much as possible, while still meeting the other criteria

In this case, if the aspect ratio of the graphic does not match the viewport, some of the viewport will extend beyond the bounds of the 'viewBox' (i.e., the area into which the 'viewBox' will draw will be smaller than the viewport).

Animatable: yes.

Example PreserveAspectRatio illustrates the various options on 'preserveAspectRatio'. The example creates several new viewports by including 'animation' elements (see Establishing a new viewport).

Example PreserveAspectRatio

7.10 Establishing a new viewport

Some elements establish a new viewport. By establishing a new viewport, you implicitly establish a new viewport coordinate system and a new user coordinate system. Additionally, there is a new meaning for percentage units defined to be relative to the current viewport since a new viewport has been established (see Units).

'viewport-fill' and 'viewport-fill-opacity' properties can be applied on the new viewport.

The bounds of the new viewport are defined by the 'x', 'y', 'width' and 'height' attributes on the element establishing the new viewport, such as an 'animation' element. Both the new viewport coordinate system and the new user coordinate system have their origins at (x, y), where x and y represent the value of the corresponding attributes on the element establishing the viewport. The orientation of the new viewport coordinate system and the new user coordinate system correspond to the orientation of the current user coordinate system for the element establishing the viewport. A single unit in the new viewport coordinate system and the new user coordinate system are the same size as a single unit in the current user coordinate system for the element establishing the viewport.

For an extensive example of creating new viewports, see Example PreserveAspectRatio.

The following elements establish new viewports:

The 'svg' element establishes the root viewport for the document.
The 'animation' element.
The 'image' element.
The 'video' element.
The 'foreignObject' element.

The following paragraph is informative.

Note that no clipping of overflow is performed, but that such clipping will take place if the content is viewed in an SVG user agent that supports clipping (e.g. a user agent that supports SVG 1.1 Full [SVG11]), since the initial value for the 'overflow' property is hidden for non-root elements that establish viewports ([SVG11], section 14.3.3). Content authors that want content to be fully forward compatible are advised to either specify the 'overflow' property or to make sure that content that shouldn't be clipped is inside of the established viewport.

7.11 Units

Besides the exceptions listed below all coordinates and lengths in SVG must be specified in user units, which means that unit identifiers are not allowed.
Two exceptions exist:

Unit identifiers are allowed on the 'width' and 'height' XML attributes on the 'svg' element.
Object bounding box units are allowed on 'linearGradient' and 'radialGradient' elements.

A user unit is a value in the current user coordinate system. For example:

Example: 07_17.svg

<text font-size="50">Text size is 50 user units</text>

For the 'svg' element's 'width' and 'height' attributes a coordinate or length value can be expressed as a number following by a unit identifier (e.g., '25cm' or '100%'). The list of unit identifiers in SVG are: in, cm, mm, pt, pc, px and percentages (%). These values on 'width' and 'height' contribute towards the calculation of the initial viewport.

Using percentage values on 'width' and 'height' attributes mandates how much space the SVG viewport must take of the available initial viewport. In particular:

For any width value expressed as a percentage of the viewport, the value to use is the specified percentage of the actual-width in user units for the nearest containing viewport, where actual-width is the width dimension of the viewport element within the user coordinate system for the viewport element.
For any height value expressed as a percentage of the viewport, the value to use is the specified percentage of the actual-height in user units for the nearest containing viewport, where actual-height is the height dimension of the viewport element within the user coordinate system for the viewport element.

See the discussion on the initial viewport for more details.

7.12 Bounding box

The bounding box (or "bbox") of an element is the tightest fitting rectangle aligned with the axes of that element's user coordinate system that entirely encloses it and its descendants. The bounding box must be computed exclusive of any values for the fill related properties, the stroke related properties, the opacity related properties or the visibility property. For curved shapes, the bounding box must enclose all portions of the shape along the edge, not just end points. Note that control points for a curve which are not defined as lying along the line of the resulting curve (e.g., the second coordinate pair of a Cubic Bézier command) must not contribute to the dimensions of the bounding box (though those points may fall within the area of the bounding box, if they lie within the shape itself, or along or close to the curve). For example, control points of a curve that are at a further distance than the curve edge, from the non-enclosing side of the curve edge, must be excluded from the bounding box.

Example bbox01 shows one shape (a 'path' element with a quadratic Bézier curve) with three possible bounding boxes, only the leftmost of which is correct.

Example: bbox01.svg

<svg xmlns='http://www.w3.org/2000/svg'
     xmlns:xlink='http://www.w3.org/1999/xlink'
     version='1.1' width='380px' height='120px' viewBox='0 0 380 120'>

  <title>Bounding Box of a Path</title>
  <desc>
    Illustration of one shape (a 'path' element with a quadratic Bézier) with
    three bounding boxes, only one of which is correct.
  </desc>

  <defs>
    <g id='shape'>
      <line x1='120' y1='50' x2='70' y2='10' stroke='#888'/>
      <line x1='20' y1='50' x2='70' y2='10' stroke='#888'/>
      <path stroke-width='2' fill='rgb(173, 216, 230)' stroke='none' fill-rule='evenodd'
            d='M20,50
               L35,100
               H120
               V50
               Q70,10 20,50'/>
      <circle cx='120' cy='50' r='3' fill='none' stroke='#888'/>
      <circle cx='20' cy='50' r='3' fill='none' stroke='#888'/>
      <circle cx='70' cy='10' r='3' fill='#888' stroke='none'/>
    </g>
  </defs>

  <g text-anchor='middle'>
    <g>
      <title>Correct Bounding Box</title>
      <use xlink:href='#shape'/>
      <rect x='20' y='30' width='100' height='70'
            fill='none' stroke='green' stroke-dasharray='2' stroke-linecap='round'/>
      <text x='70' y='115'>Correct</text>
    </g>

    <g transform='translate(120)'>
      <title>Incorrect Bounding Box</title>
      <desc>Bounding box does not encompass entire shape.</desc>
      <use xlink:href='#shape'/>
      <rect x='20' y='50' width='100' height='50'
            fill='none' stroke='red' stroke-dasharray='2' stroke-linecap='round'/>
      <text x='70' y='115'>Incorrect</text>
    </g>

    <g transform='translate(240)'>
      <title>Incorrect Bounding Box</title>
      <desc>Bounding box includes control points outside shape.</desc>
      <use xlink:href='#shape'/>
      <rect x='20' y='10' width='100' height='90'
            fill='none' stroke='red' stroke-dasharray='2' stroke-linecap='round'/>
      <text x='70' y='115'>Incorrect</text>
    </g>
  </g>
</svg>

The bounding box must be applicable for any rendering element with positive 'width' or 'height' attributes and with a 'display' property other than none, as well as for any container element that may contain such elements. Elements which do not partake in the rendering tree (e.g. elements in a 'defs' element, elements whose 'display' is none, etc.), and which have no child elements that partake in the rendering tree (e.g. 'g' elements with no children), shall not contribute to the bounding box of the parent element. Elements that do not contribute to the bounding box of a parent element must still return their own bounding box value when required.

To illustrate, example bbox-calc below shows a set of elements. Given this example, the following results shall be calculated for each of the elements.

Example: bbox-calc.svg

<svg xmlns="http://www.w3.org/2000/svg"
     xmlns:xlink="http://www.w3.org/1999/xlink">

  <title>Bounding Box Calculation</title>
  <desc>Examples of elements with different bounding box results based on context.</desc>

  <defs id="defs-1">
     <rect id="rect-1" x="20" y="20" width="40" height="40" fill="blue" />
  </defs>

  <g id="group-1">
    <use id="use-1" xlink:href="#rect-1" x="10" y="10" />

    <g id="group-2" display="none">
      <rect id="rect-2" x="10" y="10" width="100" height="100" fill="red" />
    </g>
  </g>
</svg>

Element ID	Bounding Box Result
"`defs-1`"	{0, 0, 0, 0}
"`rect-1`"	{20, 20, 40, 40}
"`group-1`"	{30, 30, 40, 40}
"`use-1`"	{30, 30, 40, 40}
"`group-2`"	{10, 10, 100, 100}
"`rect-2`"	{10, 10, 100, 100}

Elements and document fragments which derive from SVGLocatable but are not in the rendering tree, such as those in a 'defs' element or those which have been been created but not yet inserted into the DOM, must still have a bounding box. The geometry of elements outside the rendering tree must take into account only those properties and values (such as 'font-size') which are specified within that element or document fragment, or which have a lacuna value or an implementation-defined value.

For text content elements, for the purposes of the bounding box calculation, each glyph must be treated as a separate graphics element. The calculations must assume that all glyphs occupy the full glyph cell. For example, for horizontal text, the calculations must assume that each glyph extends vertically to the full ascent and descent values for the font. An exception to this is the 'textArea', which uses that element's geometry for the bounding box calculation.

Because declarative or scripted animation can change the shape, size, and position of an element, the bounding box is mutable. Thus, the bounding box for an element shall reflect the current values for the element at the snapshot in time at which the bounding box is requested, whether through a script call or as part of a declarative or linking syntax.

Note that an element which has either or both of 'width' and 'height' of '0' (such as a vertical or horizontal line, or a 'rect' element with an unspecified 'width' or 'height') still has a bounding box, with a positive value for the positive dimension, or with '0' for both 'width' and 'height' if no positive dimension is specified. Similarly, subpaths segments of a 'path' element with '0' 'width' and 'height' must be included in that element's geometry for the sake of the bounding box. Note also that elements which do not derive from SVGLocatable (such as gradient elements) do not have a bounding box, thus have no interface to request a bounding box.

Elements in the rendering tree which reference unresolved resources shall still have a bounding box, defined by the position and dimensions specified in their attributes, or by the lacuna value for those attributes if no values are supplied. For example, the element <use xlink:href="#bad" x="10" y="10"/> would have a bounding box with an 'x' and 'y' of '10' and a 'width' and 'height' of '0'.

For a formal definition of bounding boxes, see [FOLEY-VANDAM], section 15.2.3, Extents and Bounding Volumes. For further details, see bounding box calculations, the effects of visibility on bounding box, object bounding box units and text elements, and fragment identifiers.

7.13 Object bounding box units

The following elements offer the option of expressing coordinate values and lengths as fractions of the bounding box (via keyword 'objectBoundingBox') on a given element:

Element	Attribute	Effect
'linearGradient'	gradientUnits="objectBoundingBox"	Indicates that the attributes which specify the gradient vector ('x1', 'y1', 'x2', 'y2') represent fractions of the bounding box of the element to which the gradient is applied.
'radialGradient'	gradientUnits="objectBoundingBox"	Indicates that the attributes which specify the center ('cx', 'cy') and the radius ('r') represent fractions of the bounding box of the element to which the gradient is applied.

In the discussion that follows, the term applicable element is the element to which the given effect applies. For gradients the applicable element is the graphics element which has its 'fill' or 'stroke' property referencing the given gradient. (See Inheritance of painting properties. For special rules concerning text elements, see the discussion of object bounding box units and text elements.)

When keyword 'objectBoundingBox' is used, then the effect is as if a supplemental transformation matrix were inserted into the list of nested transformation matrices to create a new user coordinate system.

First, the (minx, miny) and (maxx, maxy) coordinates are determined for the applicable element and all of its descendants. The values minx, miny, maxx and maxy are determined by computing the maximum extent of the shape of the element in x and y with respect to the user coordinate system for the applicable element.

Then, coordinate (0, 0) in the new user coordinate system is mapped to the (minx, miny) corner of the tight bounding box within the user coordinate system of the applicable element and coordinate (1, 1) in the new user coordinate system is mapped to the (maxx, maxy) corner of the tight bounding box of the applicable element. In most situations, the following transformation matrix produces the correct effect:

[ (maxx-minx) 0 0 (maxy-miny) minx miny ]

Any numeric value can be specified for values expressed as a fraction of object bounding box units. In particular, fractions less are zero or greater than one can be specified.

Keyword 'objectBoundingBox' should not be used when the geometry of the applicable element has no width or no height, such as the case of a horizontal or vertical line, even when the line has actual thickness when viewed due to having a non-zero stroke width since stroke width is ignored for bounding box calculations. When the geometry of the applicable element has no width or height and 'objectBoundingBox' is specified, then the given effect (e.g., a gradient) will be ignored.

7.14 Intrinsic sizing properties of the viewport of SVG content

SVG needs to specify how to calculate some intrinsic sizing properties to enable inclusion within other languages. The intrinsic width and height of the viewport of SVG content must be determined from the 'width' and 'height' attributes. If either of these are not specified, the lacuna value of '100%' must be used. Note: the 'width' and 'height' attributes are not the same as the CSS width and height properties. Specifically, percentage values do not provide an intrinsic width or height, and do not indicate a percentage of the containing block. Rather, they indicate the portion of the viewport that is actually covered by image data.

The intrinsic aspect ratio of the viewport of SVG content is necessary for example, when including SVG from an object element in XHTML styled with CSS. It is possible (indeed, common) for an SVG graphic to have an intrinsic aspect ratio but not to have an intrinsic width or height. The intrinsic aspect ratio must be calculated based upon the following rules:

The aspect ratio is calculated by dividing a width by a height.
If the 'width' and 'height' of the rootmost 'svg' element are both specified with unit identifiers (in, mm, cm, pt, pc, px, em, ex) or in user units, then the aspect ratio is calculated from the 'width' and 'height' attributes after resolving both values to user units.
If either/both of the 'width' and 'height' of the rootmost 'svg' element are in percentage units (or omitted), the aspect ratio is calculated from the width and height values of the 'viewBox' specified for the current SVG document fragment. If the 'viewBox' is not correctly specified, or set to 'none', the intrinsic aspect ratio cannot be calculated and is considered unspecified.

Examples:

Example: Intrinsic Aspect Ratio 1

<svg xmlns="http://www.w3.org/2000/svg" version="1.2" baseProfile="tiny"
     width="10cm" height="5cm">
  ...
</svg>

In this example the intrinsic aspect ratio of the viewport is 2:1. The intrinsic width is 10cm and the intrinsic height is 5cm.

Example: Intrinsic Aspect Ratio 2

<svg xmlns="http://www.w3.org/2000/svg" version="1.2" baseProfile="tiny"
     width="100%" height="50%" viewBox="0 0 200 200">
  ...
</svg>

In this example the intrinsic aspect ratio of the rootmost viewport is 1:1. An aspect ratio calculation in this case allows embedding in an object within a containing block that is only constrained in one direction.

Example: Intrinsic Aspect Ratio 3

<svg xmlns="http://www.w3.org/2000/svg" version="1.2" baseProfile="tiny"
     width="10cm" viewBox="0 0 200 200">
  ...
</svg>

In this case the intrinsic aspect ratio is 1:1.

Example: Intrinsic Aspect Ratio 4

<svg xmlns="http://www.w3.org/2000/svg" version="1.2" baseProfile="tiny"
     width="75%" height="10cm" viewBox="0 0 200 200">
  ...
</svg>

In this example, the intrinsic aspect ratio is 1:1.

7.15 Geographic coordinate systems

In order to allow interoperability between SVG content generators and SVG user agents dealing with maps encoded in SVG, the use of a common metadata definition for describing the coordinate system used to generate SVG documents is encouraged.

Such metadata must be added under the 'metadata' element of the topmost 'svg' element describing the map, consisting of an RDF description of the Coordinate Reference System definition used to generate the SVG map [RDF]. Note that the presence of this metadata does not affect the rendering of the SVG in any way; it merely provides added semantic value for applications that make use of combined maps.

The definition must be conformant to the XML grammar described in GML 3.2.1, an OpenGIS Standard for encoding common CRS data types in XML [GML]. In order to correctly map the 2-dimensional data used by SVG, the CRS must be of subtype ProjectedCRS or Geographic2dCRS. The first axis of the described CRS maps the SVG x-axis and the second axis maps the SVG y-axis.

The main purpose of such metadata is to indicate to the user agent that two or more SVG documents can be overlayed or merged into a single document. Obviously, if two maps reference the same Coordinate Reference System definition and have the same SVG 'transform' attribute value then they can be overlayed without reprojecting the data. If the maps reference different Coordinate Reference Systems and/or have different SVG 'transform' attribute values, then a specialized cartographic user agent may choose to transform the coordinate data to overlay the data. However, typical SVG user agents are not required to perform these types of transformations, or even recognize the metadata. It is described in this specification so that the connection between geographic coordinate systems and the SVG coordinate system is clear.

7.16 The 'svg:transform' attribute

Attribute definition:

svg:transform = "<transform>" | "none"

<transform>: Specifies the affine transformation that has been applied to the map data. The syntax is identical to that described in The 'transform' attribute section.
none: Specifies that no supplemental affine transformation has been applied to the map data. Using this value has the same meaning as specifying the identity matrix, which in turn is just the same as not specifying the 'svg:transform' the attribute at all.

Animatable: no.

This attribute describes an optional additional affine transformation that may have been applied during this mapping. This attribute may be added to the OpenGIS 'CoordinateReferenceSystem' element. Note that, unlike the 'transform' attribute, it does not indicate that a transformation is to be applied to the data within the file. Instead, it simply describes the transformation that was already applied to the data when being encoded in SVG.

There are three typical uses for the 'svg:transform' global attribute. These are described below and used in the examples.

Most ProjectedCRS have the north direction represented by positive values of the second axis and conversely SVG has a y-down coordinate system. That's why, in order to follow the usual way to represent a map with the north at its top, it is recommended for that kind of ProjectedCRS to use the 'svg:transform' global attribute with a 'scale(1, -1)' value as in the third example below.
Most Geographic2dCRS have the latitude as their first axis rather than the longitude, which means that the south-north axis would be represented by the x-axis in SVG instead of the usual y-axis. That's why, in order to follow the usual way to represent a map with the north at its top, it is recommended for that kind of Geographic2dCRS to use the 'svg:transform' global attribute with a 'rotate(-90)' value as in the first example (while also adding the 'scale(1, -1)' as for ProjectedCRS).
In addition, when converting for profiles which place restrictions on precision of real number values, it may be useful to add an additional scaling factor to retain good precision for a specific area. When generating an SVG document from WGS84 geographic coordinates (EPGS 4326), we recommend the use of an additional 100 times scaling factor corresponding to an 'svg:transform' global attribute with a 'rotate(-90) scale(100)' value (shown in the second example). Different scaling values may be required depending on the particular CRS.

Below is a simple example of the coordinate metadata, which describes the coordinate system used by the document via a URI.

Example: 07_19.svg

<?xml version="1.0"?>
<svg xmlns="http://www.w3.org/2000/svg" version="1.2" baseProfile="tiny"
     width="100" height="100" viewBox="0 0 1000 1000">

  <desc>An example that references coordinate data.</desc>

  <metadata>
    <rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
             xmlns:crs="http://www.ogc.org/crs"
             xmlns:svg="http://wwww.w3.org/2000/svg">
      <rdf:Description rdf:about="">
        <!-- The Coordinate Reference System is described
             through a URI. -->
        <crs:CoordinateReferenceSystem
            svg:transform="rotate(-90)"
            rdf:resource="http://www.example.org/srs/epsg.xml#4326"/>
      </rdf:Description>
    </rdf:RDF>
  </metadata>

  <!-- The actual map content -->
</svg>

The second example uses a well-known identifier to describe the coordinate system. Note that the coordinates used in the document have had the supplied transform applied.

Example: 07_20.svg

<?xml version="1.0"?>
<svg xmlns="http://www.w3.org/2000/svg" version="1.2" baseProfile="tiny"
     width="100" height="100" viewBox="0 0 1000 1000">

  <desc>Example using a well known coordinate system.</desc>

  <metadata>
    <rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
             xmlns:crs="http://www.ogc.org/crs"
             xmlns:svg="http://wwww.w3.org/2000/svg">
      <rdf:Description rdf:about="">
        <!-- In case of a well-known Coordinate Reference System
             an 'Identifier' is enough to describe the CRS -->
        <crs:CoordinateReferenceSystem svg:transform="rotate(-90) scale(100, 100)">
          <crs:Identifier>
            <crs:code>4326</crs:code>
            <crs:codeSpace>EPSG</crs:codeSpace>
            <crs:edition>5.2</crs:edition>
          </crs:Identifier>
        </crs:CoordinateReferenceSystem>
      </rdf:Description>
    </rdf:RDF>
  </metadata>

  <!-- The actual map content -->
</svg>

The third example defines the coordinate system completely within the SVG document.

Example: 07_21.svg

<?xml version="1.0"?>
<svg xmlns="http://www.w3.org/2000/svg" version="1.2" baseProfile="tiny"
     width="100" height="100" viewBox="0 0 1000 1000">

  <desc>Coordinate metadata defined within the SVG document</desc>

  <metadata>
    <rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
             xmlns:crs="http://www.ogc.org/crs"
             xmlns:svg="http://wwww.w3.org/2000/svg">
      <rdf:Description rdf:about="">
        <!-- For other CRS it should be entirely defined -->
        <crs:CoordinateReferenceSystem svg:transform="scale(1,-1)">
          <crs:NameSet>
            <crs:name>Mercator projection of WGS84</crs:name>
          </crs:NameSet>
          <crs:ProjectedCRS>
            <!-- The actual definition of the CRS -->
            <crs:CartesianCoordinateSystem>
              <crs:dimension>2</crs:dimension>
              <crs:CoordinateAxis>
                <crs:axisDirection>north</crs:axisDirection>
                <crs:AngularUnit>
                  <crs:Identifier>
                    <crs:code>9108</crs:code>
                    <crs:codeSpace>EPSG</crs:codeSpace>
                    <crs:edition>5.2</crs:edition>
                  </crs:Identifier>
                </crs:AngularUnit>
              </crs:CoordinateAxis>
              <crs:CoordinateAxis>
                <crs:axisDirection>east</crs:axisDirection>
                <crs:AngularUnit>
                  <crs:Identifier>
                    <crs:code>9108</crs:code>
                    <crs:codeSpace>EPSG</crs:codeSpace>
                    <crs:edition>5.2</crs:edition>
                  </crs:Identifier>
                </crs:AngularUnit>
              </crs:CoordinateAxis>
            </crs:CartesianCoordinateSystem>
            <crs:CoordinateReferenceSystem>
              <!-- the reference system of that projected system is
                         WGS84 which is EPSG 4326 in EPSG codeSpace -->
              <crs:NameSet>
                <crs:name>WGS 84</crs:name>
              </crs:NameSet>
              <crs:Identifier>
                <crs:code>4326</crs:code>
                <crs:codeSpace>EPSG</crs:codeSpace>
                <crs:edition>5.2</crs:edition>
              </crs:Identifier>
            </crs:CoordinateReferenceSystem>
            <crs:CoordinateTransformationDefinition>
              <crs:sourceDimensions>2</crs:sourceDimensions>
              <crs:targetDimensions>2</crs:targetDimensions>
              <crs:ParameterizedTransformation>
                <crs:TransformationMethod>
                  <!-- the projection is a Mercator projection which is
                        EPSG 9805 in EPSG codeSpace -->
                  <crs:NameSet>
                    <crs:name>Mercator</crs:name>
                  </crs:NameSet>
                  <crs:Identifier>
                    <crs:code>9805</crs:code>
                    <crs:codeSpace>EPSG</crs:codeSpace>
                    <crs:edition>5.2</crs:edition>
                  </crs:Identifier>
                  <crs:description>Mercator (2SP)</crs:description>
                </crs:TransformationMethod>
                <crs:Parameter>
                  <crs:NameSet>
                    <crs:name>Latitude of 1st standart parallel</crs:name>
                  </crs:NameSet>
                  <crs:Identifier>
                    <crs:code>8823</crs:code>
                    <crs:codeSpace>EPSG</crs:codeSpace>
                    <crs:edition>5.2</crs:edition>
                  </crs:Identifier>
                  <crs:value>0</crs:value>
                </crs:Parameter>
                <crs:Parameter>
                  <crs:NameSet>
                    <crs:name>Longitude of natural origin</crs:name>
                  </crs:NameSet>
                  <crs:Identifier>
                    <crs:code>8802</crs:code>
                    <crs:codeSpace>EPSG</crs:codeSpace>
                    <crs:edition>5.2</crs:edition>
                  </crs:Identifier>
                  <crs:value>0</crs:value>
                </crs:Parameter>
                <crs:Parameter>
                  <crs:NameSet>
                    <crs:name>False Easting</crs:name>
                  </crs:NameSet>
                  <crs:Identifier>
                    <crs:code>8806</crs:code>         
                    <crs:codeSpace>EPSG</crs:codeSpace>
                    <crs:edition>5.2</crs:edition>
                  </crs:Identifier>
                  <crs:value>0</crs:value>
                </crs:Parameter>
                <crs:Parameter>
                  <crs:NameSet>
                    <crs:name>False Northing</crs:name>
                  </crs:NameSet>
                  <crs:Identifier>
                    <crs:code>8807</crs:code>
                    <crs:codeSpace>EPSG</crs:codeSpace>
                    <crs:edition>5.2</crs:edition>
                  </crs:Identifier>
                  <crs:value>0</crs:value>
                </crs:Parameter>
              </crs:ParameterizedTransformation>
            </crs:CoordinateTransformationDefinition>
          </crs:ProjectedCRS>
        </crs:CoordinateReferenceSystem>
      </rdf:Description>
    </rdf:RDF>
  </metadata>

  <!-- the actual map content -->
</svg>

Command	Name	Parameters	Description
M (absolute) m (relative)	moveto	(x y)+	A new sub-path at the given (x,y) coordinate shall be started. This shall also establish a new current point at the given coordinate. If a relative 'moveto' (m) appears as the first element of the 'path', then it shall treated as a pair of absolute coordinates. If a 'moveto' is followed by multiple pairs of coordinates, the subsequent pairs shall be treated as implicit 'lineto' commands.

Command	Name	Parameters	Description
Z or z	closepath	(none)	The current subpath shall be closed by drawing a straight line from the current point to current subpath's initial point, which then shall become the new current point. Since the Z and z commands take no parameters, they have an identical effect.

Command	Name	Parameters	Description
L (absolute) l (relative)	lineto	(x y)+	A line shall be drawn from the current point to the given (x,y) coordinate, which then shall become the new current point. If more than one coordinate pair is specified, a polyline shall be drawn. At the end of the command, the new current point shall be set to the final set of coordinates provided.
H (absolute) h (relative)	horizontal lineto	x+	A horizontal line shall be drawn from the current point (cpx, cpy) to (x, cpy). If more than one x value is specified, multiple horizonal lines shall be drawn (although usually this doesn't make sense). At the end of the command, the new current point shall be (x, cpy) for the final value of x.
V (absolute) v (relative)	vertical lineto	y+	A vertical line shall be drawn from the current point (cpx, cpy) to (cpx, y). If more than one y value is specified, multiple vertical lines shall be drawn (although usually this doesn't make sense). At the end of the command, the new current point shall be (cpx, y) for the final value of y.

Command	Name	Parameters	Description
C (absolute) c (relative)	curveto	(x1 y1 x2 y2 x y)+	A cubic Bézier curve shall be drawn from the current point to (x,y) using (x1,y1) as the control point at the beginning of the curve and (x2,y2) as the control point at the end of the curve. If multiple sets of coordinates are specified, a polybézier shall be drawn. At the end of the command, the new current point shall be the final (x,y) coordinate pair used in the polybézier.
S (absolute) s (relative)	shorthand/smooth curveto	(x2 y2 x y)+	A cubic Bézier curve shall be drawn from the current point to (x,y). The first control point shall be the reflection of the second control point on the previous command relative to the current point. (If there is no previous command or if the previous command was not an C, c, S or s, the first control point shall be coincident with the current point.) (x2,y2) shall be used as the second control point (i.e., the control point at the end of the curve). If multiple sets of coordinates are specified, a polybézier shall be drawn. At the end of the command, the new current point shall be the final (x,y) coordinate pair used in the polybézier.

Command	Name	Parameters	Description
Q (absolute) q (relative)	quadratic Bézier curveto	(x1 y1 x y)+	A quadratic Bézier curve is drawn from the current point to (x,y) using (x1,y1) as the control point. If multiple sets of coordinates are specified, a polybézier shall be drawn. At the end of the command, the new current point shall be the final (x,y) coordinate pair used in the polybézier.
T (absolute) t (relative)	Shorthand/smooth quadratic Bézier curveto	(x y)+	A quadratic Bézier curve is drawn from the current point to (x,y). The control point shall be the reflection of the control point on the previous command relative to the current point. (If there is no previous command or if the previous command was not a Q, q, T or t, the control point shall be current point.) If multiple sets of coordinates are specified, a polybézier shall be drawn. At the end of the command, the new current point shall be the final (x,y) coordinate pair used in the polybézier.

10 Text

10.1 Introduction
10.2 Characters and their corresponding glyphs
10.3 Fonts, font tables and baselines
10.4 The 'text' element
10.5 The 'tspan' element
10.6 Text layout
- 10.6.1 Text layout introduction
- 10.6.2 Relationship with bidirectionality
- 10.6.3 The 'direction' property
- 10.6.4 The 'unicode-bidi' property
10.7 Text rendering order
10.8 Alignment properties
- 10.8.1 Text alignment properties
10.9 Font selection properties
10.10 White space handling
10.11 Text in an area
- 10.11.1 Introduction to text in an area
- 10.11.2 The 'textArea' element
- 10.11.3 The 'tbreak' element
- 10.11.4 The 'line-increment' property
- 10.11.5 The 'text-align' property
- 10.11.6 The 'display-align' property
- 10.11.7 Text in an area layout rules
10.12 Editable text fields
- 10.12.1 The 'editable' attribute
10.13 Text selection and clipboard operations
10.14 Text search

10.1 Introduction

Text that is to be rendered as part of an SVG document fragment is specified using the text content block elements. The characters to be drawn are expressed as XML content inside the element.

SVG's text content block elements are rendered like other graphics elements. Thus, coordinate system transformations and painting features apply to text elements in the same way as they apply to shapes such as paths and rectangles.

Each 'text' element causes a single string of text to be rendered. The 'text' element performs no automatic line breaking or word wrapping. To achieve the effect of multiple lines of text, use one of the following methods:

Use the 'textArea' element to specify a rectangular area in which to flow the text.
Pre-compute the line breaks (which can be done by the author or authoring tool) and use individual 'text' elements to manually place the lines of text. (Note: this is discouraged for accessibility reasons.)
Express the text to be rendered in another XML namespace such as XHTML [XHTML] embedded inline within a 'foreignObject' element. (Note: the exact semantics of this approach are not completely defined at this time.)

The text strings within 'text' elements shall be rendered in one straight line. SVG supports the following international text processing features for straight line text:

left-to-right or bidirectional text (i.e., languages which intermix right-to-left and left-to-right text, such as Arabic and Hebrew)
when SVG fonts are used, automatic selection of the correct glyph corresponding to the current form for Arabic and Han text

The layout rules for straight line text are described in Text layout.

Because SVG text is packaged as XML content:

Text data in SVG content is readily accessible to the visually impaired (see Accessibility Support)
In many viewing scenarios, the user will be able to search for and select text strings and copy selected text strings to the system clipboard (see Text search and Text selection and clipboard operations)
XML-compatible Web search engines will find text strings in SVG content with no additional effort over what they need to do to find text strings in other XML documents

Multi-language SVG content is possible by substituting different text strings based on the user's preferred language.

For accessibility reasons, it is recommended that text which is included in a document have appropriate semantic markup to indicate its function. See SVG accessibility guidelines for more information.

10.2 Characters and their corresponding glyphs

In XML [XML10, XML11], textual content is defined in terms of a sequence of XML characters, where each character is defined by a particular Unicode code point [UNICODE]. Fonts, on the other hand, consist of a collection of glyphs and other associated information, such as font tables. A glyph is a presentable form of one or more characters (or a part of a character in some cases). Each glyph consists of some sort of identifier (in some cases a string, in other cases a number) along with drawing instructions for rendering that particular glyph.

In many cases, there is a one-to-one mapping of Unicode characters (i.e., Unicode code points) to glyphs in a font. For example, it is common for a font designed for Latin languages (where the term Latin is used for European languages such as English with alphabets similar to or derivative to the Latin language) to contain a single glyph for each of the standard ASCII characters (i.e., A-to-Z, a-to-z, 0-to-9, plus the various punctuation characters found in ASCII). Thus, in most situations, the string "XML", which consists of three Unicode characters, would be rendered by the three glyphs corresponding to "X", "M" and "L", respectively.

In various other cases, however, there is not a strict one-to-one mapping of Unicode characters to glyphs. Some of the circumstances when the mapping is not one-to-one:

Ligatures — For best looking typesetting, it is often desirable that particular sequences of characters are rendered as a single glyph. An example is the word "office". Many fonts will define an "ffi" ligature. When the word "office" is rendered, sometimes the user agent will render the glyph for the "ffi" ligature instead of rendering distinct glyphs (i.e., "f", "f" and "i") for each of the three characters. Thus, for ligatures, multiple Unicode characters map to a single glyph. Note that for proper rendering of many languages, ligatures are required for certain character combinations, and are not optional typographic features. For example, this is the case for most languages throughout South and South East Asia.
Composite characters — In many situations, commonly used adornments such as diacritical marks will be stored once in a font as a particular glyph and then composed with one or more other glyphs to result in the desired character. For example, it is possible that a font engine might render the é character by first rendering the glyph for e and then rendering the glyph for ´ (the accent mark) such that the accent mark will appear over the e. In this situation, a single Unicode character maps to multiple glyphs.
Context-sensitive glyph positioning — In many scripts, the precise positioning of the glyph for a given character (especially diacritics) will vary according to the visual context. For example, Thai tone marks are rendered above the base consonant, but need to be moved upwards further if a vowel-sign also appears above the base consonant. The same character is used in memory, but the final location of the glyph is sensitive to context.
Complex positioning of character glyphs — In scripts such as those used for Indian languages, a combining vowel character that appears after a base consonant in memory may be displayed to the left of the base consonant, or on two sides of the base consonant, (i.e., the left-most glyph in rendered text may not be the first character in a text element.) Indeed, such vowel characters may be rendered to the left of, or on more than one side of, a cluster of consonants that ends with the character they follow in memory. On the other hand, a Hindi RA character at the beginning of a consonant cluster in memory may be displayed over a following vowel sign to the right of the following syllabic cluster. The location, from left to right, in which glyphs are displayed in these scripts can differ significantly from the order of the characters in memory.
Glyph substitution — Many typography systems examine the nature of the textual content and utilize different glyphs in different circumstances. For example, in Arabic, the same Unicode character might render as any of four different glyphs, depending on such factors as whether the character appears at the start, the end or the middle of a sequence of cursively joined characters. Different glyphs might be used for a punctuation character depending on inline-progression-direction (e.g., horizontal vs. vertical). In these situations, a single Unicode character might map to one of several alternative glyphs.
In many languages, particular sequences of characters will be converted into multiple glyphs such that parts of a particular character are in one glyph and the remainder of that character is in another glyph.

In many situations, the algorithms for mapping from characters to glyphs are system-dependent, resulting in the possibility that the rendering of text might be (usually slightly) different when viewed in different user environments. If the author of SVG content requires precise selection of fonts and glyphs, then it is recommended that the necessary fonts (potentially subsetted to include only the glyphs needed for the given document) be available either as SVG fonts embedded within the SVG content or as WebFonts posted at the same Web location as the SVG content.

Throughout this chapter, the term character shall be equivalent to the definition of a character in XML [XML11].

10.3 Fonts, font tables and baselines

A font consists of a collection of glyphs together with the information (the font tables) necessary to use those glyphs to present characters on some medium. The combination of the collection of glyphs and the font tables is called the font data. The font tables include the information necessary to map characters to glyphs, to determine the size of glyph areas and to position the glyph area. Each font table consists of one or more font characteristics, such as the 'font-weight' and 'font-style'.

The geometric font characteristics are expressed in a coordinate system based on the EM box. (The EM is a relative measure of the height of the glyphs in the font; see CSS2 em square ([CSS2], section 15.4.3).) The box 1 EM high and 1 EM wide is called the design space. This space is given geometric coordinates by sub-dividing the EM into a number of units-per-em ([CSS2], section 15.3.4).

Note: Units-per-em is a font characteristic. A typical value for units-per-EM is 1000 or 2048.

The coordinate space of the EM box is called the design space coordinate system. For scalable fonts, the curves and lines that are used to draw a glyph are represented using this coordinate system.

Note: Most often, the (0,0) point in this coordinate system is positioned on the left edge of the EM box, but not at the bottom left corner. The Y coordinate of the bottom of a roman capital letter is usually zero. And the descenders on lowercase roman letters have negative coordinate values.

SVG assumes that the font tables will provide at least three font characteristics: an ascent, a descent and a set of baseline-tables. The ascent is the distance to the top of the EM box from the (0,0) point of the font; the descent is the distance to the bottom of the EM box from the (0.0) point of the font. The baseline-table is explained below.

Note: Within an OpenType font, for horizontal writing-modes, the ascent and descent are given by the sTypoAscender and sTypoDescender entries in the OS/2 table. For vertical writing-modes, the descent (the distance, in this case from the (0,0) point to the left edge of the glyph) is normally zero because the (0,0) point is on the left edge. The ascent for vertical writing-modes is either 1 em or is specified by the ideographic top baseline value in the OpenType Base table for vertical writing-modes.

In horizontal writing-modes, the glyphs of a given script are positioned so that a particular point on each glyph, the alignment-point, is aligned with the alignment-points of the other glyphs in that script. The glyphs of different scripts, for example, Western, Northern Indic and Far-Eastern scripts, are typically aligned at different points on the glyph. For example, Western glyphs are aligned on the bottoms of the capital letters, northern indic glyphs are aligned at the top of a horizontal stroke near the top of the glyphs and far-eastern glyphs are aligned either at the bottom or center of the glyph. Within a script and within a line of text having a single font-size, the sequence of alignment-points defines, in the inline-progression-direction, geometric line called a baseline. Western and most other alphabetic and syllabic glyphs are aligned to an "alphabetic" baseline, the northern indic glyphs are aligned to a "hanging" baseline and the far-eastern glyphs are aligned to an "ideographic" baseline.

A baseline-table specifies the position of one or more baselines in the design space coordinate system. The function of the baseline table is to facilitate the alignment of different scripts with respect to each other when they are mixed on the same text line. Because the desired relative alignments may depend on which script is dominant in a line (or block), there may be a different baseline table for each script. In addition, different alignment positions are needed for horizontal and vertical writing modes. Therefore, the font may have a set of baseline tables: typically, one or more for horizontal writing-modes and zero or more for vertical writing-modes.

Note: Some fonts may not have values for the baseline tables. Heuristics are suggested for approximating the baseline tables when a given font does not supply baseline tables.

SVG further assumes that for each glyph in the font data for a font, there is a width value, an alignment-baseline and an alignment-point for horizontal writing-mode. (Vertical writing-mode is not supported in SVG Tiny 1.2.)

In addition to the font characteristics required above, a font may also supply substitution and positioning tables that can be used by a formatter to re-order, combine and position a sequence of glyphs to make one or more composite glyphs. The combination may be as simple as a ligature, or as complex as an indic syllable which combines, usually with some re-ordering, multiple consonants and vowel glyphs.

10.4 The 'text' element

The 'text' element defines a graphics element consisting of text. The XML content within the 'text' element, along with relevant attributes and properties and character-to-glyph mapping tables within the font itself, define the glyphs to be rendered. (See Characters and their corresponding glyphs.) The attributes and properties on the 'text' element indicate such things as the writing direction, font specification and painting attributes which describe how exactly to render the characters. Subsequent sections of this chapter describe the relevant text-specific attributes and properties, in particular text layout and bidirectionality.

Since 'text' elements are rendered using the same rendering methods as other graphics elements, all of the same coordinate system transformations and painting features that apply to shapes such as paths and rectangles also apply to 'text' elements.

Text behaves like other graphical objects, and it is therefore possible to apply a gradient to text. When this facility is applied to text then the object bounding box units are computed relative to the entire 'text' element in all cases, even when different effects are applied to different 'tspan' elements within the same 'text' element.

The 'text' element renders its first glyph (after bidirectionality reordering) at the initial current text position, which is established by the 'x' and 'y' attributes on the 'text' element (with possible adjustments due to the value of the 'text-anchor' property). After the glyph(s) corresponding to the given character is (are) rendered, the current text position is updated for the next glyph. In the simplest case, the new current text position is the previous current text position plus the glyph's advance value. See text layout for a description of glyph placement and glyph advance.

Schema: text

    <define name='text'>
      <element name='text'>
        <ref name='text.AT'/>
        <zeroOrMore><ref name='svg.TextCommon.group'/></zeroOrMore>
      </element>
    </define>

    <define name='text.AT' combine='interleave'>
      <ref name='svg.Properties.attr'/>
      <ref name='svg.Core.attr'/>
      <ref name='svg.Conditional.attr'/>
      <ref name='svg.FocusHighlight.attr'/>
      <ref name='svg.Editable.attr'/>
      <ref name='svg.Focus.attr'/>
      <ref name='svg.Transform.attr'/>
      <optional>
        <attribute name='x' svg:animatable='true' svg:inheritable='false'>
          <ref name='Coordinates.datatype'/>
        </attribute>
      </optional>
      <optional>
        <attribute name='y' svg:animatable='true' svg:inheritable='false'>
          <ref name='Coordinates.datatype'/>
        </attribute>
      </optional>
      <optional>
        <attribute name='rotate' svg:animatable='true' svg:inheritable='false'>
          <ref name='Numbers.datatype'/>
        </attribute>
      </optional>
    </define>

Attribute definitions:

x = "<list-of-coordinates>"

If a single <coordinate> is provided, then the value represents the new absolute X coordinate for the current text position for rendering the glyphs that correspond to the first character within this element or any of its descendants.

If a comma- or space-separated list of n <coordinate>s is provided, then the values represent new absolute X coordinates for the current text position for rendering the glyphs corresponding to each of the first n characters within this element or any of its descendants.

If more <coordinate>s are provided than there are characters, then the extra <coordinate>s must be ignored.

If more characters are provided than <coordinate>s, then for each of these extra characters normal text layout processing describied in the Text layout section shall occur.

At least one <coordinate> value must be specified in the attribute.

The lacuna value is '0'.

Animatable: yes.

y = "<list-of-coordinates>"

The corresponding list of absolute Y coordinates for the glyphs corresponding to the characters within this element. The processing rules for the 'y' attribute parallel the processing rules for the 'x' attribute.

At least one <coordinate> value must be specified in the attribute.

The lacuna value is '0'.

Animatable: yes.

editable = "none" | simple"

This attribute indicates whether the text can be edited. See the definition of the 'editable' attribute.

Animatable: yes.

rotate = "<list-of-numbers>"

This attribute indicates the supplemental rotation about the alignment-point that must be applied to the glyphs corresponding to characters within this element according to the following rules:

A comma- or space-separated list of <number>s must be provided. The first <number> specifies the supplemental rotation that must be applied to the glyphs corresponding to the first character within this element or any of its descendants, the second <number> specifies the supplemental rotation that must be applied to the glyphs that correspond to the second character, and so on.

If more <number>s are provided than there are characters, then the extra <number>s must be ignored.

If more characters are provided than <number>s, then for each of these extra characters the rotation value specified by the last number must be used.

Where multiple characters map to one glyph, the rotation specified for the first character of the ligature should be used for the glyph, and the subsequent rotations for the other contributing characters should be ignored.

At least one <number> value must be specified in the attribute.

This supplemental rotation must have no impact on the rules by which current text position as glyphs get rendered.

Animatable: yes (non-additive, 'set' and 'animate' elements only).

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

See attribute definition for description.

Animatable: yes.

Navigation Attributes

See definition.

Example text01 below contains the text string "Hello, out there" which will be rendered onto the canvas using the Verdana font family with the glyphs filled with the color blue.

Example: 10_01.svg

<?xml version="1.0"?>
<svg xmlns="http://www.w3.org/2000/svg" version="1.2" baseProfile="tiny"
     width="10cm" height="3cm" viewBox="0 0 1000 300">

  <desc>Example text01 - 'Hello, out there' in blue</desc>

  <text x="250" y="150" 
        font-family="Verdana" font-size="55" fill="blue">
    Hello, out there
  </text>

  <!-- Show outline of canvas using 'rect' element -->
  <rect x="1" y="1" width="998" height="298"
        fill="none" stroke="blue" stroke-width="2"/>
</svg>

10.5 The 'tspan' element

Within a text content block element, graphic and font properties can be adjusted by including a 'tspan' element.

Schema: tspan

    <define name='tspan'>
      <element name='tspan'>
        <ref name='tspan.AT'/>
        <zeroOrMore><ref name='svg.TextCommon.group'/></zeroOrMore>
      </element>
    </define>

    <define name='tspan.AT' combine='interleave'>
      <ref name='svg.Properties.attr'/>
      <ref name='svg.FocusHighlight.attr'/>
      <ref name='svg.Core.attr'/>
      <ref name='svg.Conditional.attr'/>
      <ref name='svg.Focus.attr'/>
    </define>

The following examples show basic use of the 'tspan' element.

Example tspan01 uses a 'tspan' element to indicate that the word "not" is to use a bold font and have red fill.

Example: 10_03.svg

<?xml version="1.0"?>
<svg xmlns="http://www.w3.org/2000/svg" version="1.2" baseProfile="tiny"
     width="10cm" height="3cm" viewBox="0 0 1000 300">

  <desc>Example tspan01 - using tspan to change visual attributes</desc>

  <g font-family="Verdana" font-size="45">
    <text x="200" y="150" fill="blue">
      You are
        <tspan font-weight="bold" fill="red" >not</tspan>
      a banana.
    </text>
  </g>

  <!-- Show outline of canvas using 'rect' element -->
  <rect x="1" y="1" width="998" height="298"
        fill="none" stroke="blue" stroke-width="2"/>
</svg>

Within a text content block element, graphic and font properties can be adjusted by including a 'tspan' element. Positional attributes such as 'x', 'y', and 'rotate' are not available on 'tspan' in SVG Tiny 1.2.

Attribute definitions:

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

See attribute definition for description.

Animatable: yes.

Navigation Attributes

See definition.

10.6 Text layout

10.6.1 Text layout introduction

This section describes the text layout features supported by SVG. Text layout is described in a general and directionally neutral way, to provide a single reference point for layout information which applies to left-to-right (e.g., Latin scripts), bidirectional (e.g., Hebrew or Arabic) and vertical (e.g., Asian scripts). In SVG Tiny 1.2, vertical writing is not supported. The descriptions in this section assume straight line text (i.e., text that is either strictly horizontal or vertical with respect to the current user coordinate system).

For each text content block element, the SVG user agent determines the current reference orientation. The reference orientation is the vector pointing towards negative infinity in Y within the current user coordinate system. (Note: in the initial coordinate system, the reference orientation is up.)

Based on the reference orientation the SVG user agent determines the current inline-progression-direction. For left-to-right text, the inline-progression-direction points 90 degrees clockwise from the reference orientation vector. For right-to-left text, the inline progression points 90 degrees counter-clockwise from the reference orientation vector.

Based on the reference orientation the SVG user agent determines the current block-progression-direction. For left-to-right and right-to-left text, the block-progression-direction points 180 degrees from the reference orientation vector because the only available horizontal writing modes are lr-tb and rl-tb.

In processing a given text content block element, the SVG user agent keeps track of the current text position. The initial current text position is established by the 'x' and 'y' attributes on the text content block element.

The current text position is adjusted after each glyph to establish a new current text position at which the next glyph shall be rendered. The adjustment to the current text position is based on the current inline-progression-direction, glyph-specific advance values corresponding to the glyph orientation of the glyph just rendered, kerning tables in the font and the current values of various attributes and properties, such as the spacing properties and any 'x' and 'y' attributes on text content block elements. If a glyph does not provide explicit advance values corresponding to the current glyph orientation, then an appropriate approximation should be used. For vertical text, a suggested approximation is the sum of the ascent and descent values for the glyph. Another suggested approximation for an advance value for both horizontal and vertical text is the size of an em (see 'units-per-em').

For each glyph to be rendered, the SVG user agent determines an appropriate alignment-point on the glyph which will be placed exactly at the current text position. The alignment-point is determined based on glyph cell metrics in the glyph itself, the current inline-progression-direction and the glyph orientation relative to the inline-progression-direction. For most uses of Latin text the alignment-point in the glyph will be the intersection of left edge of the glyph cell (or some other glyph-specific x-axis coordinate indicating a left-side origin point) with the Latin baseline of the glyph. For many cases with top-to-bottom vertical text layout, the reference point will be either a glyph-specific origin point based on the set of vertical baselines for the font or the intersection of the center of the glyph with its top line (see [CSS2] section 15.3.8 for a definition of top line). If a glyph does not provide explicit origin points corresponding to the current glyph orientation, then an appropriate approximation should be used, such as the intersection of the left edge of the glyph with the appropriate horizontal baseline for the glyph or intersection of the top edge of the glyph with the appropriate vertical baseline. If baseline tables are not available, user agents should establish baseline tables that reflect common practice.

Adjustments to the current text position are either absolute position adjustments or relative position adjustments. An absolute position adjustment occurs in the following circumstances:

At the start of a 'text' element
At the start of a 'textArea' element
For each character within a 'text' element which has an 'x' or 'y' attribute value assigned to it explicitly

All other position adjustments to the current text position are relative position adjustments.

Each absolute position adjustment defines a new text chunk. Absolute position adjustments impact text layout in the following ways:

Ligatures only occur when a set of characters which might map to a ligature are all in the same text chunk.
Each text chunk represents a separate block of text for alignment due to 'text-anchor' property values.
Reordering of characters due to bidirectionality only occurs within a text chunk. Reordering does not happen across text chunks.

The following additional rules apply to ligature formation:

As in the discussion of the CSS2 spacing properties ([CSS2], section 16.4), when the resultant space between two characters is not the same as the default letter spacing, user agents should either not use ligatures or not apply letter-spacing depending on their knowledge of which behavior will produce the most coherent results for the script being used (for example, when the letter-spacing is high it is likely that breaking ligatures will produce the best result with Roman scripts, but be less than optimal for Arabic scripts, where ignoring the letter-spacing and maintaining the ligatures will be preferred).
Ligature formation must only occur between characters that are not separated by element markup, and must still be enabled between characters separated by other XML markup, such as comments, processing instructions, or CDATA sections. Ligature processing must take place only after entity and character references have been resolved. For example, assuming that there is a ligature defined for the string "dahut" and that the '&hu-ent;' entity reference contains the string "hu", in all the following examples the "dahut" ligature will be enabled:
- <text>Le dahut vit dans les Alpes grenobloises.</text>
- <text>Le da&hu-ent;t vit dans les Alpes grenobloises.</text>
- <text>Le dahut vit dans les Alpes grenobloises.</text>
- <text>Le da<?turn around?>hut vit dans les Alpes grenobloises.</text>
- <text>Le da<![CDATA[hu]>t vit dans les Alpes grenobloises.</text>
But it will not be enabled in the following case:
- <text>Le da<tspan fill='orange'>h</tspan>ut vit dans les Alpes grenobloises.</text>
As mentioned above, ligature formation should not be enabled for the glyphs corresponding to characters within different text chunks.

10.6.2 Relationship with bidirectionality

The characters in certain scripts are written from right to left. In some documents, in particular those written with the Arabic or Hebrew script, and in some mixed-language contexts, text in a single line may appear with mixed directionality. This phenomenon is called bidirectionality, or "bidi" for short.

The Unicode standard ([UNICODE], specifically [UAX9]) defines a complex algorithm for determining the proper directionality of text. The algorithm consists of an implicit part based on character properties, as well as explicit controls for embeddings and overrides. The SVG user agent applies this bidirectional algorithm when determining the layout of characters within a text content block element.

The 'direction' and 'unicode-bidi' properties allow authors to override the inherent directionality of the content characters and thus explicitly control how the elements and attributes of a document language map to this algorithm. These two properties are applicable to all characters whose glyphs are perpendicular to the inline-progression-direction.

In many cases, the bidirectional algorithm from Unicode [UNICODE] produces the desired result automatically, and in such cases the author does not need to use these properties. For other cases, such as when using right-to-left languages, it may be sufficient to add the 'direction' property to the rootmost 'svg' element, and allow that direction to inherit to all text elements, as in the following example (which may be used as a template):

Example: rtl-text.svg

<svg xmlns="http://www.w3.org/2000/svg"
     width="100%" height="100%" viewBox="0 0 400 400"
     direction="rtl" xml:lang="fa">

  <title direction="ltr" xml:lang="en">Right-to-left Text</title>
  <desc direction="ltr" xml:lang="en">
    A simple example for using the 'direction' property in documents
    that predominantly use right-to-left languages.
  </desc>

  <text x="200" y="200" font-size="20">داستان SVG Tiny 1.2 طولا ني است.</text>

</svg>

Below is another example, where where implicit bidi reordering is not sufficient:

Example: rtl-complex.svg

<?xml version="1.0" encoding="utf-8"?>
<svg xmlns="http://www.w3.org/2000/svg"
     width="100%" height="100%" viewBox="0 0 400 400"
     direction="rtl" xml:lang="he">

  <title direction="ltr" xml:lang="en">Right-to-left Text</title>
  <desc direction="ltr" xml:lang="en">
    An example for using the 'direction' and 'unicode-bidi' properties
    in documents that predominantly use right-to-left languages.
  </desc>

  <text x="200" y="200" font-size="20"> כתובת 
	MAC:&#x200F;
    	<tspan direction="ltr" unicode-bidi="embed">00-24-AF-2A-55-FC</tspan> 
	</text>

</svg>

Within text content elements, the alignment of text with regards to the 'text-anchor' or 'text-align' properties is determined by the value of the 'direction' property. For example, given a 'text' element with a 'text-anchor' value of "end", for a 'direction' value of "ltr", the text will extend to the left of the position of the 'text' element's 'x' attribute value, while for 'direction' value of "rtl", the text will extend to the right of the position of the 'text' element's 'x' attribute value.

A more complete discussion of bidirectionality can be found in the Text direction section of CSS 2 ([CSS2], section 9.10).

The processing model for bidirectional text is as follows. The user agent processes the characters which are provided in logical order (i.e., the order the characters appear in the original document). The user agent determines the set of independent blocks within each of which it should apply the Unicode bidirectional algorithm. Each text chunk represents an independent block of text. After processing the Unicode bidirectional algorithm and properties 'direction' and 'unicode-bidi' on each of the independent text blocks, the user agent will have a potentially re-ordered list of characters which are now in left-to-right rendering order. While kerning or ligature processing might be font-specific, the preferred model is that kerning and ligature processing occurs between combinations of characters or glyphs after the characters have been re-ordered.

10.6.3 The 'direction' property

'direction'

Value:	ltr \| rtl \| inherit
Initial:	ltr
Applies to:	text content elements
Inherited:	yes
Percentages:	N/A
Media:	visual
Animatable:	no

This property specifies the base writing direction of text and the direction of embeddings and overrides (see 'unicode-bidi') for the Unicode bidirectional algorithm. For the 'direction' property to have any effect on an element that does not by itself establish a new text chunk (such as the 'tspan' element in SVG 1.2 Tiny), the 'unicode-bidi' property's value must be embed or bidi-override.

Note: though this property can be declared on any element for purposes of inheritance, it only affects text content. It does not effect the coordinate system or the positioning of shapes.

Except for any additional information provided in this specification, the normative definition of the property is found in CSS 2 ([CSS2], section 9.10).

10.6.4 The 'unicode-bidi' property

'unicode-bidi'

Value:	normal \| embed \| bidi-override \| inherit
Initial:	normal
Applies to:	text content elements
Inherited:	no
Percentages:	N/A
Media:	visual
Animatable:	no

Except for any additional information provided in this specification, the normative definition of the property is found in CSS 2 ([CSS2], section 9.10).

10.7 Text rendering order

The glyphs associated with the characters within text content block elements are rendered in the logical order of the characters in the original document, independent of any re-ordering necessary for visual display (e.g to implement bidirectionality). Thus, for text that goes right-to-left visually, the glyphs associated with the rightmost character are rendered before the glyphs associated with the other characters, as they come earlier in logical order.

Additionally, each distinct glyph is rendered in its entirety (i.e., it is filled and stroked as specified by the 'fill' and 'stroke' properties) before the next glyph gets rendered.

10.8 Alignment properties

10.8.1 Text alignment properties

The 'text-anchor' property is used to align a string of text relative to a given point, along a given axis. This axis of alignment varies by writing mode; for horizontal writing mode (the norm for Latin or Arabic) the axis is horizontal, while for vertical writing mode (often used for Japanese) the axis is vertical. (Note: SVG Tiny 1.2 does not include support for vertical text.) The point of orientation depends upon the 'text-anchor' property value.

The 'text-anchor' property is applied to each individual text chunk within a given 'text' element. Each text chunk has an initial current text position, which represents the point in the user coordinate system resulting from (depending on context) application of the 'x' and 'y' attributes on the 'text' element assigned explicitly to the first rendered character in a text chunk.

'text-anchor'

Value:	start \| middle \| end \| inherit
Initial:	start
Applies to:	'text' Element
Inherited:	yes
Percentages:	N/A
Media:	visual
Animatable:	yes
Computed value:	Specified value, except inherit

Values have the following meanings (where right, left, top, and bottom refer to alignment in an untransformed coordinate space):

start: The rendered characters are aligned such that the start of the resulting rendered text is at the initial current text position. For an element with a 'direction' property value of "ltr" (typical for most European languages), the left side of the text is rendered at the initial text position. For an element with a 'direction' property value of "rtl" (typical for Arabic and Hebrew), the right side of the text is rendered at the initial text position. For an element with a vertical primary text direction (often typical for Asian text), the top side of the text is rendered at the initial text position. (Note: SVG Tiny 1.2 does not include support for vertical text.)
middle: The rendered characters are aligned such that the geometric middle of the resulting rendered text is at the initial current text position.
end: The rendered characters are aligned such that the end of the resulting rendered text is at the initial current text position. For an element with a 'direction' property value of "ltr" (typical for most European languages), the right side of the text is rendered at the initial text position. For an element with a 'direction' property value of "rtl" (typical for Arabic and Hebrew), the left side of the text is rendered at the initial text position. For an element with a vertical primary text direction (often typical for Asian text), the bottom of the text is rendered at the initial text position. (Note: SVG Tiny 1.2 does not include support for vertical text.)

10.9 Font selection properties

SVG uses the following font specification properties. Except for any additional information provided in this specification, the normative definition of the property is in XSL 1.1 ([XSL], section 7.9).

'font-family'

Value:	[[ <family-name> \| <generic-family> ],]* [<family-name> \| <generic-family>] \| inherit
Initial:	depends on user agent
Applies to:	text content elements
Inherited:	yes
Percentages:	N/A
Media:	visual
Animatable:	yes
Computed value:	Specified value, except inherit

This property indicates which font family is to be used to render the text, specified as a prioritized list of font family names and/or generic family names. Except for any additional information provided in this specification, the normative definition of the property is in XSL 1.1 ([XSL], section 7.9.2).

'font-style'

Value:	normal \| italic \| oblique \| inherit
Initial:	normal
Applies to:	text content elements
Inherited:	yes
Percentages:	N/A
Media:	visual
Animatable:	yes
Computed value:	Specified value, except inherit

This property specifies whether the text is to be rendered using a normal, italic or oblique face. The font-style value "backslant" defined in XSL 1.1 is not supported. Except for any additional information provided in this specification, the normative definition of the property is in XSL 1.1 ([XSL], section 7.9.7).

'font-variant'

Value:	normal \| small-caps \| inherit
Initial:	normal
Applies to:	text content elements
Inherited:	yes
Percentages:	N/A
Media:	visual
Animatable:	yes
Computed value:	Specified value, except inherit

This property indicates whether the text is to be rendered using the normal glyphs for lowercase characters or using small-caps glyphs for lowercase characters. Except for any additional information provided in this specification, the normative definition of the property is in XSL 1.1 ([XSL], section 7.9.8).

'font-weight'

Value:	normal \| bold \| bolder \| lighter \| 100 \| 200 \| 300 \| 400 \| 500 \| 600 \| 700 \| 800 \| 900 \| inherit
Initial:	normal
Applies to:	text content elements
Inherited:	yes
Percentages:	N/A
Media:	visual
Animatable:	yes
Computed value:	one of the legal numeric values, non-numeric values shall be converted to numeric values according to the rules defined below.

This property refers to the boldness or lightness of the glyphs used to render the text, relative to other fonts in the same font family. Except for any additional information provided in this specification, the normative definition of the property is in XSL 1.1 ([XSL], section 7.9.9).

Non-numeric values are interpreted as follows:

normal: Same as "400".
bold: Same as "700".
bolder: Specifies the next weight that is assigned to a font that is darker than the inherited one. If there is no such weight, it simply results in the next darker numerical value (and the font remains unchanged), unless the inherited value was "900", in which case the resulting weight is also "900".
lighter: Specifies the next weight that is assigned to a font that is lighter than the inherited one. If there is no such weight, it simply results in the next lighter numerical value (and the font remains unchanged), unless the inherited value was "100", in which case the resulting weight is also "100".

'font-size'

Value:	<absolute-size> \| <relative-size> \| <length> \| inherit
Initial:	medium
Applies to:	text content elements
Inherited:	yes, the computed value is inherited
Percentages:	N/A
Media:	visual
Animatable:	yes
Computed value:	Absolute length

This property refers to the size of the font from baseline to baseline when multiple lines of text are set solid in a multiline layout environment. The SVG user agent processes the <length> as a height value in the current user coordinate system. Percentage values are not supported.

Except for any additional information provided in this specification, the normative definition of the property is in XSL 1.1 ([XSL], section 7.9.4).

10.10 White space handling

SVG supports the standard XML attribute 'xml:space' to specify the handling of white space characters within a given text content block element's character data. Note that any child element of a text content block element may also have an 'xml:space' attribute which will apply to that child element's text content. The SVG user agent has special processing rules associated with this attribute as described below. These are behaviors that occur subsequent to XML parsing [XML11] and do not affect the contents of the Document Object Model (DOM) [DOM3].

Attribute definition:

xml:space = "default" | "preserve"

An inheritable attribute which can have one of two values:

default: The initial value for 'xml:space'. When xml:space="default", the SVG user agent will do the following using a copy of the original character data content. First, it will remove all newline characters. Then it will convert all tab characters into space characters. Then, it will strip off all leading and trailing space characters. Then, all contiguous space characters will be consolidated.
preserve: When xml:space="preserve", the SVG user agent will do the following using a copy of the original character data content. It will convert all newline and tab characters into space characters. Then, it will draw all space characters, including leading, trailing and multiple contiguous space characters. Thus, when drawn with xml:space="preserve", the string "a b" (three spaces between "a" and "b") will produce a larger separation between "a" and "b" than "a b" (one space between "a" and "b").

Animatable: no.

The following example illustrates that line indentation can be important when using xml:space="default". The fragment below show two pairs of similar 'text' elements, with both 'text' elements using xml:space='default'. For these examples, there is no extra white space at the end of any of the lines (i.e., the line break occurs immediately after the last visible character).

[01]  <text xml:space='default'>
[02]    WS example
[03]    indented lines
[04]  </text>
[05]  <text xml:space='preserve'>WS example indented lines</text>
[06]
[07]  <text xml:space='default'>
[08]WS example
[09]non-indented lines
[10]  </text>
[11]  <text xml:space='preserve'>WS examplenon-indented lines</text>

The first pair of 'text' elements above show the effect of indented character data. The attribute xml:space='default' in the first 'text' element instructs the SVG user agent to:

convert all tabs (if any) to space characters,
strip out all line breaks (i.e., strip out the line breaks at the end of lines [01], [02] and [03]),
strip out all leading space characters (i.e., strip out space characters before "WS example" on line [02]),
strip out all trailing space characters (i.e., strip out space characters before "</text>" on line [04]),
consolidate all intermediate space characters (i.e., the space characters before "indented lines" on line [03]) into a single space character.

The second pair of 'text' elements above show the effect of non-indented character data. The attribute xml:space='default' in the third 'text' element instructs the SVG user agent to:

convert all tabs (if any) to space characters,
strip out all line breaks (i.e., strip out the line breaks at the end of lines [07], [08] and [09]),
strip out all leading space characters (there are no leading space characters in this example),
strip out all trailing space characters (i.e., strip out space characters before "</text>" on line [10]),
consolidate all intermediate space characters into a single space character (in this example, there are no intermediate space characters).

Note that XML parsers are required to convert the standard representations for a newline indicator (e.g., the literal two-character sequence "#xD#xA" or the stand-alone literals #xD or #xA) into the single character #xA before passing character data to the application. See XML end-of-line handling ([XML11], section 2.11).

Any features in the SVG language or the SVG DOM that are based on character position number are based on character position after applying the white space handling rules described here. In particular, if xml:space="default", it is often the case that white space characters are removed as part of processing. Character position numbers index into the text string after the white space characters have been removed per the rules in this section.

10.11 Text in an area

10.11.1 Introduction to text in an area

The 'textArea' element allows simplistic wrapping of text content within a given region. This profile of SVG specifies a single rectangular region. Other profiles may allow a sequence of arbitrary shapes.

Text wrapping via the 'textArea' element is available as a lightweight and convenient facility for simple text wrapping where a complete box model layout engine is not required.

The layout of wrapped text is user agent dependent; thus, content developers need to be aware that there might be different results, particularly with regard to where line breaks occur.

The minimal layout facilities required for text in an area are described in text in an area layout rules.

Example textArea01 below contains a text string which will wrap into a rectangular area. Any text which does not fit will not be rendered.

Example: textArea01.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="1.2" baseProfile="tiny" viewBox="0 0 220 320">

  <title>Basic textflow</title>

  <textArea font-size="25" font-family="Georgia" x="10" y="10" width="200" 
        height="300">Tomorrow, and tomorrow, and
        tomorrow; creeps in this petty pace from day to day, until the last syll&#xAD;able of recorded
        time. And all our yesterdays have lighted fools the way to dusty death.</textArea>
  <rect x="5" y="5" width="210" height="310" stroke-width="3" stroke="#777" fill="none"/>
</svg>

10.11.2 The 'textArea' element

Schema: textArea

    <define name='textArea'>
      <element name='textArea'>
        <ref name='textArea.AT'/>
        <zeroOrMore>
          <choice>
            <element name='tspan'>
              <ref name='tspan.AT'/>
              <zeroOrMore>
                <choice>
                  <ref name='tbreak'/>
                  <ref name='svg.TextCommon.group'/>
                </choice>
              </zeroOrMore>
            </element>
            <ref name='svg.TextCommon.group'/>
          </choice>
        </zeroOrMore>
      </element>
    </define>

    <define name='textArea.AT' combine='interleave'>
      <ref name='svg.Properties.attr'/>
      <ref name='svg.FocusHighlight.attr'/>
      <ref name='svg.Core.attr'/>
      <ref name='svg.Conditional.attr'/>
      <ref name='svg.Focus.attr'/>
      <ref name='svg.Transform.attr'/>
      <ref name='svg.XY.attr'/>
      <ref name='svg.Editable.attr'/>
      <optional>
        <attribute name='width' svg:animatable='true' svg:inheritable='false'>
          <choice>
            <ref name='Length.datatype'/>
            <value>auto</value>
          </choice>
        </attribute>
      </optional>
      <optional>
        <attribute name='height' svg:animatable='true' svg:inheritable='false'>
        <choice>
          <ref name='Length.datatype'/>
          <value>auto</value>
        </choice>
        </attribute>
      </optional>
    </define>

Attribute definitions:

x = "<coordinate>"

The x-axis coordinate of one corner of the rectangular region into which the text content will be placed. The lacuna value is '0'.

Animatable: yes.

y = "<coordinate>"

The y-axis coordinate of one corner of the rectangular region into which the text content will be placed. The lacuna value is '0'.

Animatable: yes.

width = "auto" | "<coordinate>"

The width of the rectangular region into which the text content will be placed. A value of 'auto' indicates that the width of the rectangular region is infinite. The lacuna value is 'auto'.

Animatable: yes.

height = "auto" | "<coordinate>"

The height of the rectangular region into which the text content will be placed. A value of 'auto' indicates that the height of the rectangular region is infinite. The lacuna value is 'auto'.

Animatable: yes.

editable = "none" | "simple"

This attribute indicates whether the text can be edited. See the definition of the 'editable' attribute.

Animatable: yes.

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

See attribute definition for description.

Animatable: yes

Navigation Attributes

See definition.

If both 'width' and 'height' have the value 'auto', the text will be rendered in a single line along the direction of the text progression until all the text is rendered, or until a line-breaking element such as 'tbreak' is encountered, in which case the remaining text is rendered on a new line.

10.11.3 The 'tbreak' element

The 'tbreak' element is an empty element that forcibly breaks the current line of text, even if the current line of text is empty (i.e. multiple consecutive 'tbreak' elements each cause a line break.)

Schema: tbreak

    <define name='tbreak'>
      <element name='tbreak'>
        <ref name='tbreak.AT'/>
        <empty/>
      </element>
    </define>

    <define name='tbreak.AT' combine='interleave'>
      <ref name='svg.Core.attr'/>
      <ref name='svg.Conditional.attr'/>
    </define>

The 'tbreak' element has no attributes aside from the standard core and conditional attributes.

10.11.4 The 'line-increment' property

The 'line-increment' property provides limited control over the size of each line in the block-progression-direction. This property applies to the 'textArea' element, and to child elements of the 'textArea' element. The 'line-increment' property must not have any effect when used on an element which is not, or does not have as an ancestor, a 'textArea' element.

'line-increment'

Value:	auto \| <number> \| inherit
Initial:	auto
Applies to:	'textArea', 'tspan' and 'tbreak' elements
Inherited:	yes
Percentages:	N/A
Media:	visual
Animatable:	yes
Computed value:	Specified value, except inherit

Values for the property have the following meaning:

auto: Subsequent lines are offset from the previous line by the maximum font-size for any glyphs drawn within that line, multiplied by some reasonable value for default line spacing. This specification recommends a value of 1.1 for this multiplier.
<number>: Subsequent lines are offset from the previous line by this amount (in user units). Negative values are unsupported.

10.11.5 The 'text-align' property

Alignment in the inline progression direction in flowing text is provided by the text-align property. It is a modified version of the XSL 1.1 text-align property ([XSL], section 7.16.9).

'text-align'

Value:	start \| end \| center \| inherit
Initial:	start
Applies to:	textArea elements
Inherited:	yes
Percentages:	N/A
Media:	visual
Animatable:	yes

For details refer to the XSL 1.1 text-align property ([XSL], section 7.16.9). Note that SVG does not require user agents to support the following values for this property: justify, inside, outside, <string>, left, or right. The lacuna value is start.

As with the 'text-anchor' property, the values start and end are dependent on the value of the 'direction' property (typically, as appropriate for the writing system being used).

For left to right horizontal (French, Russian, Thai, etc.): start is left and end is right
For right to left horizontal (Hebrew, Arabic, etc.): start is right and end is left
For top to bottom vertical (vertical Chinese, etc.): start is top and end is bottom (Note: SVG Tiny 1.2 does not include support for vertical text.)

10.11.6 The 'display-align' property

The 'display-align' property specifies the alignment, in the block-progression-direction, of the text content of the 'textArea' element.

'display-align'

Value:	auto \| before \| center \| after \| inherit
Initial:	auto
Applies to:	'textArea'
Inherited:	yes
Percentages:	N/A
Media:	visual
Animatable:	yes
Computed value:	Specified value, except inherit

Values for the property have the following meaning:

auto: For SVG, auto is equivalent to before.
before: The before-edge of the first line is aligned with the before-edge of the first region.
center: The lines are centered in the block-progression-direction.
after: The after-edge of the last line is aligned with the after-edge of the last region.

The following sentence is informative: For a better understanding of the 'display-align' property this diagram from the XSL specification (the final diagram in [XSL], section 4.2.3) illustrates the correspondence between the various edge names for a mixed writing-mode example (western and japanese writing-mode).

10.11.7 Text in an area layout rules

Text in an area layout is defined as a post processing step to the standard text layout model of SVG.

A conformant SVG user agent can implement a simplistic layout algorithm which consists simply of inserting line breaks whenever the content explicitly specifies a line break with a 'tbreak' element or when the current line cannot fit all of the remaining glyphs. Any lines of glyphs that do not completely fit within the region(s) are not rendered.

SVG user agents should implement a line-breaking algorithm that supports at a minimum the features described below as a post processing step to SVG's standard text layout model.

The text is processed in logical order to determine line breaking opportunities between characters, according to Unicode Standard Annex No. 14 [UAX14].
Text layout is performed as normal, on one infinitely long line; soft hyphens are included in the line. The result is a set of positioned Glyphs.
The first line is positioned such that its before edge is flush against the region's before edge, relative to the block-progression-direction.
Glyphs represent a character or characters within a word. Each glyph is associated with the word that contains its respective characters. In cases where characters from multiple words contribute to the same glyph, the words are merged and all the glyphs are treated as part of the earliest word in logical order.
The glyphs from a word are collapsed into Glyph Groups. A Glyph Group is comprised of all consecutive glyphs from the same word. In most cases, each word generates one glyph group; however, in some cases the interaction between BIDI and special markup may cause glyphs from one word to have glyphs from other words embedded in it.
Each Glyph Group has two extents calculated: its normal extent, and its last in text area extent. Its normal extent is the sum of the advances of all glyphs in the group except soft hyphens. The normal extent is the extent used when a Glyph Group from a later word is in the same text area. The last in text area extent includes the advance of a trailing soft hyphen, but does not include the advance of trailing white space or non-spacing combining marks. The last in text region extent is used when this glyph group is from the last word (in logical order) in this text area. (If the entire line consists of a single word which is not breakable, the SVG user agent may choose to force a break in the line so that at least some text will appear for the given line.)
If xml:space="default", any space character that causes a line break in a 'textArea' element will be consumed by the line break and thus not rendered. However, if xml:space="preserve", any space character that causes a line break and subsequent spaces that will not fit on the line shall be included in the next line.
Words are added to the current line in logical order. All the Glyph Groups from a word must be in the same line, and all the glyphs from a Glyph Group must be in the same 'textArea'.
If 'line-increment' is a number, then each line will be sized in the block-progression-direction to the value of 'line-increment'. If 'line-increment' is auto, then the maximum 'font-size' for any glyph in the line will determine the size of the line in the block-progression-direction. When a word is added, the line increment may increase; it can never decrease from the first word. An increase in the line increment can only reduce the space available for text placement in the span. The span will have the maximum possible number of words. The position of the dominant baseline for a given line is determined by first computing the line-increment value for that line and then choosing a position for the dominant baseline, using the position where the given baseline would appear for the font that will be used to render the first character and an assumed font-size equal to the line-increment value.
The Glyphs from the Glyph Groups are then collapsed into the text regions by placing the first selected glyph (in display order) at the start of the text area and each subsequent glyph at the location of the glyph following the preceding selected glyph (in display order).
The next word is selected, and the next line location is determined. The next line is positioned such that its before edge is flush against the after edge of the previous line relative to the block-progression-direction. Go to step 8.
Any lines which extend outside of the area(s) in the block-progression-direction are not rendered.

10.12 Editable text fields

SVG Tiny 1.2 allows text elements to be edited. Although simple text editing can be implemented directly in script, implementing an intuitive and well internationalized text input system which works on a variety of platforms is complex.Therefore, this functionality is provided by the SVG user agent, which has access to system text libraries. Content authors can build higher level widgets, such as form entry fields, on top of the editable text functionality.

10.12.1 The 'editable' attribute

The text content block elements have an editable attribute which specifies whether the contents of the elements can be edited in place.

Schema: editable

    <define name='svg.Editable.attr' combine='interleave'>
      <optional>
        <attribute name='editable' svg:animatable='true' svg:inheritable='false'>
          <choice>
            <value>none</value>
            <value>simple</value>
          </choice>
        </attribute>
      </optional>
    </define>

Attribute definition:

editable = "none" | "simple"

If set to 'none' (the lacuna value), SVG editing facilities are not provided for the contents of the text content block elements. If set to 'simple', the SVG user agent must provide a way for the user to edit the content of the text content block elements and all contained subelements which are not hidden (with visibility="hidden") or removed from the rendering tree (through the 'switch' element or display="none").

If a clipboard is supported by the platform, the SVG user agent must also provide a way to cut or copy the selected text from the element to the clipboard, and to paste text from the clipboard into the element.

Whenever the 'editable' attribute is set to 'simple', the 'focusable' attribute is considered to be set to 'true', irrespective of what the actual value is.

Animatable: yes.

SVG user agents should allow for the editing of text in-place. However, editing with a modal editing dialog is an alternate possibility, and may be the only option on some platforms. The current editing position should be indicated, for example with a caret. SVG Tiny 1.2 user agents must also support system functions such as copy/paste and drag/drop if they are available to applications on the platform.

To start editing, the current presentation value of the 'editable' attribute must be 'simple', the text content block element must have focus, and it must then be activated, e.g. by using an Enter key or clicking on the text region with a pointer device. When editing text in a text field, all text and key events are dispatched to the SVG user agent, which processes the events for proper handling of text entry.

If a text content block element is editable, then the SVG user agent must not normalize white space in user input when changing the tree according to the input. However, the displayed text must be rendered according to the SVG rules for 'xml:space'.

For editing in-place the following functionality must be made available:

movement to the next/previous character (in logical order), for example with Left/Right arrows
in 'textArea' elements, movement to the next/previous line, for example with the Down/Up keys
movement to the beginning of the line, for example with the Home key
movement to the end of the line, for example with the End key
copy/cut/paste, if a clipboard is supported, for example with Copy and Paste keys

The functionality should use the normal key bindings that are used for those tasks on the given platform. For devices without keyboard access, the equivalent system input methods should be used wherever possible to provide the functionality described above.

When doing editing in-place, the content of the DOM nodes that are being edited should be live at all times and reflect the current state of the edited string as it is being edited. When using a modal editing dialog, the content of the DOM nodes will only change once the user commits the edit (for example, by using an Enter key or clicking an "OK" button, or an alike behavior native to the platform), firing a single textInput event.

If an Input Method Editor (IME) is used (for example, to input Kanji text, or to input Latin text using number keys on mobile phones), the text events correspond to the actual text entered (eg the Kanji character, or the Latin character) and not to the keyboard or mouse gestures needed to produce it (such as the sequence of kana characters, or the number of sequential presses of a numeric key).

While text is being edited, the SVG user agent should always make the caret visible to the user as it is moved around the edited text (either due to typing more characters or to moving it within existing text). The precise behavior in which this functionality is supported depends on the SVG user agent.

The behavior of edited text while the caret is placed inside a ligature is implementation dependent. SVG user agents are however encouraged to take into account the notions captured in Character Model for the World Wide Web 1.0: Fundamentals, Section 6.1: String concepts [CHARMOD].

If the text of an editable element is edited, and the element has child elements, the contents of the edited element must first be stripped of all non-'tbreak' elements, preserving the contents of each non-'tbreak' element in place.

If the editable element does not have text content, it may not be possible to activate the editability with a pointer, since there will be no rendered element to click on. In the case of the 'textArea' element, which has inherent 'width' and 'height' geometry, setting the 'pointer-events' property value to boundingBox will allow the user to initiate the editing (see Example textArea02). This functionality does not exist for the 'text' element since it has no inherent geometry without text content.

Example textArea02 below shows how to use the 'pointer-events' property value boundingBox to create a declarative input box that can be activated with a pointer device.

Example: textArea02.svg

<?xml version="1.0" encoding="UTF-8"?>
<svg xmlns="http://www.w3.org/2000/svg"
     version="1.2" baseProfile="tiny" viewBox="0 0 250 100">

  <title>Editable text input</title>
  <desc>Illustrates how to create an editable input box without script</desc>

  <rect x='0' y='0' width='250' height='100' fill='#87ceeb'>
    <title>background rectangle</title>
  </rect>

  <g id="nameInput" transform='translate(50, 20)'>
    <text x="0" y="20" font-size="18" font-family="Arial" fill="#000080">Name:</text>
    <rect x="0" y="25" width="156" height="26" rx="3" ry="3"
          fill="white" stroke-width="2" stroke="#000080"/>
    <textArea x="3" y="27" width="150" height="20" font-size="18" font-family="Arial"
              editable="simple" focusable="true" pointer-events="boundingBox"/>
  </g>

</svg>

10.13 Text selection and clipboard operations

If SVG viewers support text selection and copy/paste operations then they must support:

user selection of text strings in SVG content
the ability to copy selected text strings to the system clipboard

A text selection operation starts when all of the following occur:

the user positions the pointing device or caret over a glyph that has been rendered as part of a text content block element, initiates a select operation (e.g., pressing the standard system mouse button for select operations) and then moves the current text position while continuing the select operation (e.g., continuing to press the standard system mouse button for select operations);
no other visible graphics element has been painted above the glyph at the point at which the pointing device was clicked.

As the text selection operation proceeds (e.g., the user continues to press the given mouse button), all associated events with other graphics elements are ignored (i.e., the text selection operation is modal) and the SVG user agent shall dynamically indicate which characters are selected by an appropriate highlighting technique, such as redrawing the selected glyphs with inverse colors. As the current text position is moved during the text selection process, the end glyph for the text selection operation is the glyph within the same 'text' element whose glyph cell is closest to the pointer. All characters within the 'text' element whose position within the 'text' element is between the start of selection and end of selection shall be highlighted, regardless of position on the canvas and regardless of any graphics elements that might be above the end of selection point.

Once the text selection operation ends (e.g., the user releases the given mouse button), the selected text will stay highlighted until an event occurs which cancels text selection, such as a pointer device activation event (e.g., pressing a mouse button).

Detailed rules for determining which characters to highlight during a text selection operation are provided in Text selection implementation notes.

For systems which have system clipboards, the SVG user agent should provide a user interface for initiating a copy of the currently selected text to the system clipboard. It is sufficient for the SVG user agent to post the selected text string in the system's appropriate clipboard format for plain text, but it is preferable if the SVG user agent also posts a rich text alternative which captures the various font properties associated with the given text string.

For bidirectional text, the SVG user agent must support text selection in logical order, which will result in discontinuous highlighting of glyphs due to the bidirectional reordering of characters. SVG user agents can also optionally provide an alternative ability to select bidirectional text in visual rendering order (i.e., after bidirectional text layout algorithms have been applied), with the result that selected character data might be discontinuous logically. In this case, if the user requests that bidirectional text be copied to the clipboard, then the SVG user agent is required to make appropriate adjustments to copy only the visually selected characters to the clipboard.

When feasible, it is recommended that generators of SVG attempt to order their text strings to facilitate properly ordered text selection within SVG viewing applications such as Web browsers.

In addition to discrete text selection, the SVG user agent should provide facility for the mass selection of entire text passages, for whatever text is in scope. If a text content element has focus, such a select-all operation should include only the contents of that element. If no text content element is in focus, the select-all operation should select all the text in the document. This may be a progressive operation, widening the scope with each subsequent operation. For example, a common idiom is to allow a user to select text with a single click on a word, with first the word selected, then the entire passage with a second click, then the entire document with a third click. For purposes of accessibility, the user agent must allow any such operation to be performed by keyboard as well as pointer device (such as in the ctrl/command+A "select-all" keyboard shortcut), and should also expose appropriate accessibility APIs.

10.14 Text search

If the user agent supports searching for text strings, then it must support searching for text strings in SVG content as well. An SVG viewer which supports search must allow the user to find all instances of the searched text string within the document that are in the rendering tree (e.g., those with a 'display' property other than none), and must highlight or otherwise indicate each instance. SVG viewers which allow sequential searches for text strings must pan and zoom the viewport, as appropriate, in order to show the text string in context, and are recommended to adjust the viewport as if there had been a fragment identifier link traversal to the element containing the text string.

In other words, if the containing text content element is too large to be enclosed in the viewport, the SVG user agent is recommended to zoom out, but if the text does fit, the user agent is recommended only to pan, and not to zoom. In order to enable maximum usability, authors should create their content accordingly, breaking text into discrete text content elements that fit within the expected viewport at a readable size, while providing sufficient context. Additionally, users must be provided a way to zoom in on text that is too small for the user to read.

Example 'text_search.svg' below contains a long text string which extends outside of the initial viewport, and which needs to be adjusted when searching for one of the words outside the viewport. The image shows the results of a text search using the Batik SVG toolkit.

Example: text_search.svg

<svg xmlns="http://www.w3.org/2000/svg" version="1.2"
     width="100%" height="100%" viewBox="0 0 120 60">

  <title>Text Search</title>
  <desc>
    An example of text that extends beyond the viewport,
    requiring the user agent to pan the viewport when 
    words are searched for.
  </desc>  
  
  <!-- 
    This rectangle is the same position and dimensions as the viewBox, 
    illustrating the initial area of the viewport.   
  -->
  <rect x="0" y="0" width="120" height="60" fill="#6495ed" stroke="blue" />
  
  <!-- 
    The contents of this text element extend beyond the initial viewport.   
  -->
  <text x="120" y="35" text-anchor="middle" fill="blue" 
        font-size="10" font-family="Helvetica">
        Seek and you shall find, find and you will search.
  </text>

</svg>

11 Painting: Filling, Stroking, Colors and Paint Servers

11.1 Introduction
11.2 Specifying paint
11.3 Fill properties
11.4 Stroke properties
11.5 Non-scaling stroke
11.6 Simple alpha compositing
- 11.6.1 Compositing the currentColor value
11.7 The 'viewport-fill' property
11.8 The 'viewport-fill-opacity' property
11.9 Controlling visibility and rendering
11.10 Rendering hints
- 11.10.1 The 'color-rendering' property
- 11.10.2 The 'shape-rendering' property
- 11.10.3 The 'text-rendering' property
- 11.10.4 The 'image-rendering' property
- 11.10.5 The 'buffered-rendering' property
11.11 Inheritance of painting properties
11.12 Object and group opacity: the 'opacity' property
11.13 Color
- 11.13.1 Syntax for color values
- 11.13.2 HTML color keywords
11.14 Paint servers
- 11.14.1 System paint servers
- 11.14.2 The 'solidColor' element
- 11.14.3 The 'color' property
11.15 Gradients
- 11.15.1 Linear gradients
- 11.15.2 Radial gradients
- 11.15.3 Defining gradient stops: the 'stop' element

11.1 Introduction

Graphics elements, including text content elements and shapes, can be filled (which means painting the interior of the object) and stroked (which means painting along the outline of the object). Filling and stroking both can be thought of in more general terms as painting operations.

With SVG, you can paint (i.e., fill or stroke) with:

a single color, possibly with some level of transparency
a gradient (linear or radial)

SVG uses the general notion of a paint server. Apart from system paint, paint servers are specified using a local IRI reference on a 'fill' or 'stroke' property. Gradients and colors are just specific types of paint servers.

11.2 Specifying paint

Properties 'fill' and 'stroke' take on a value of type <paint>, which is specified as follows:

<paint>:

none: Indicates that no paint shall be applied.
currentColor: Indicates that painting shall be done using the color specified by the current animated value of the 'color' property. This mechanism is provided to facilitate sharing of color attributes between parent grammars such as other (non-SVG) XML. This mechanism allows you to define a style in your HTML which sets the 'color' property and then pass that style to the SVG user agent so that your SVG text will draw in the same color.
<color>: the explicit color (in the sRGB color space [SRGB]).
<FuncIRI> [ none | currentColor | <color>]: The <FuncIRI> specifies a paint server such as a gradient. The fragment identifier of the <FuncIRI> provides a link to the paint server (e.g., a gradient or 'solidColor') that shall be used to paint the current object. SVG Tiny 1.2 user agents are only required to support local IRI references. If the IRI reference is invalid (for example, it points to an object that doesn't exist or the object is not a valid paint server or it is a non-local IRI reference and the viewer does not support it), then the fallback value (if specified) is used; otherwise it must be treated as if none was specified.
<system paint>: A system paint server

11.3 Fill properties

'fill'

Value:	<paint> \| inherit (See Specifying paint)
Initial:	black
Applies to:	shapes and text content elements
Inherited:	yes
Percentages:	N/A
Media:	visual
Animatable:	yes
Computed value:	"none", system paint, specified <color> value or absolute IRI

The 'fill' property specifies that the interior of the given graphical element must be painted. The area to be painted shall consist of any areas inside the outline of the shape. To determine the inside of the shape, all subpaths must be considered, and the interior shall be determined according to the rules associated with the current value of the 'fill-rule' property. The zero-width geometric outline of a shape must be included in the area to be painted.

Open subpaths must be filled by performing the fill operation as if an additional "closepath" command were added to the path to connect the last point of the subpath with the first point of the subpath. Thus, fill operations apply to both open subpaths within 'path' elements (i.e., subpaths without a closepath command) and 'polyline' elements.

'fill-rule'

Value:	nonzero \| evenodd \| inherit
Initial:	nonzero
Applies to:	shapes and text content elements
Inherited:	yes
Percentages:	N/A
Media:	visual
Animatable:	yes
Computed value:	Specified value, except inherit

The 'fill-rule' property indicates the algorithm which must be used to determine what parts of the canvas are included inside the shape. For a simple, non-intersecting path, it is intuitively clear what region lies "inside"; however, for a more complex path, such as a path that intersects itself or where one subpath encloses another, the interpretation of "inside" is not so obvious.

The 'fill-rule' property provides two options for how the inside of a shape is determined:

nonzero

The following algorithm, or any other that gives the same result, must be used to determine the "insideness" of a point on the canvas. Draw a ray from the point to infinity in any direction and then examine the places where a segment of the shape crosses the ray. Starting with a count of zero, add one each time a path segment crosses the ray from left to right and subtract one each time a path segment crosses the ray from right to left. After counting the crossings, if the result is zero then the point is outside the path. Otherwise, it is inside. The following drawing illustrates the nonzero rule:

Image showing nonzero fill rule

View this example as SVG (SVG-enabled browsers only)

evenodd

The following algorithm, or any other that gives the same result, must be used to determine the "insideness" of a point on the canvas. Draw a ray from the point to infinity in any direction and counting the number of path segments from the given shape that the ray crosses. If this number is odd, the point is inside; if even, the point is outside. The following drawing illustrates the evenodd rule:

Image showing evenodd fill rule

View this example as SVG (SVG-enabled browsers only)

(Note: the above explanations do not specify what to do if a path segment coincides with or is tangent to the ray. Since any ray will do, one may simply choose a different ray that does not have such problem intersections.)

'fill-opacity'

Value:	<opacity-value> \| inherit
Initial:	1
Applies to:	shapes and text content elements
Inherited:	yes
Percentages:	N/A
Media:	visual
Animatable:	yes
Computed value:	Specified value, except inherit

'fill-opacity' specifies the opacity of the painting operation which shall be used to paint the interior the current object. (See Painting shapes and text.)

<opacity-value>: The opacity of the painting operation that is to be used to fill the current object. Any values outside the range 0.0 (fully transparent) to 1.0 (fully opaque) must be clamped to this range. (See Clamping values which are restricted to a particular range.)

Related property: 'stroke-opacity'.

11.4 Stroke properties

The following are the properties which affect how an element is stroked.

In all cases, strokes which are affected by directionality, such as those having dash patterns, must be rendered such that the stroke operation starts at the same point at which the graphics element starts. In particular, for 'path' elements, the start of the path is the first point of the initial "moveto" command.

For strokes, such as dash patterns whose computations are dependent on progress along the outline of the graphics element, distance calculations must use the SVG user agent's standard distance along a path algorithms.

When stroking is performed using a complex paint server, such as a gradient, the stroke operation must be identical to the result that would have occurred if the geometric shape defined by the geometry of the current graphics element and its associated stroking properties were converted to an equivalent 'path' element and then filled using the given paint server.

'stroke'

Value:	<paint> \| inherit (See Specifying paint)
Initial:	none
Applies to:	shapes and text content elements
Inherited:	yes
Percentages:	N/A
Media:	visual
Animatable:	yes
Computed value:	"none", system paint, specified <color> value or absolute IRI

The 'stroke' property shall paint along the outline of the given graphics element.

A subpath (see Paths) consisting of a single moveto shall not be stroked. A subpath consisting of a moveto and lineto to the same exact location or a subpath consisting of a moveto and a closepath shall not be stroked if the 'stroke-linecap' property has a value of butt and shall be stroked if the 'stroke-linecap' property has a value of round or square, producing respectively a circle or a square centered at the given point.

This property contributes to an element's decorated bounding box.

'stroke-width'

Value:	<length> \| inherit
Initial:	1
Applies to:	shapes and text content elements
Inherited:	yes
Percentages:	N/A
Media:	visual
Animatable:	yes
Computed value:	Specified value, except inherit

<length>: The width of the stroke which shall be used on the current object.
No stroke shall be painted for a zero value. A negative value is unsupported and must be treated as if the stroke had not been specified.

This property contributes to an element's decorated bounding box.

'stroke-linecap'

Value:	butt \| round \| square \| inherit
Initial:	butt
Applies to:	shapes and text content elements
Inherited:	yes
Percentages:	N/A
Media:	visual
Animatable:	yes
Computed value:	Specified value, except inherit

'stroke-linecap' specifies the shape which shall be used at the end of open subpaths when they are stroked.

butt: The shape drawn at the end of open subpaths shall be as per the drawing below.
round: The shape drawn at the end of open subpaths shall be as per the drawing below.
square: The shape drawn at the end of open subpaths shall be as per the drawing below.

Image showing stroke-linecap alternatives

View this example as SVG (SVG-enabled browsers only)

This property contributes to an element's decorated bounding box.

'stroke-linejoin'

Value:	miter \| round \| bevel \| inherit
Initial:	miter
Applies to:	shapes and text content elements
Inherited:	yes
Percentages:	N/A
Media:	visual
Animatable:	yes
Computed value:	Specified value, except inherit

'stroke-linejoin' specifies the shape which shall be used at the corners of shapes when they are stroked.

miter: The shape drawn at the corner of shapes shall be as per the drawing below.
round: The shape drawn at the corner of shapes shall be as per the drawing below.
bevel: The shape drawn at the corner of shapes shall be as per the drawing below.

Image showing stroke-linejoin alternatives

View this example as SVG (SVG-enabled browsers only)

This property contributes to an element's decorated bounding box.

'stroke-miterlimit'

Value:	<miterlimit> \| inherit
Initial:	4
Applies to:	shapes and text content elements
Inherited:	yes
Percentages:	N/A
Media:	visual
Animatable:	yes
Computed value:	Specified value, except inherit

When two line segments meet at a sharp angle and miter joins have been specified for 'stroke-linejoin', it is possible for the miter to extend far beyond the thickness of the line stroking the path. The 'stroke-miterlimit' imposes a limit on the ratio of the miter length to the 'stroke-width'. When the limit is exceeded, the join must be converted from a miter to a bevel.

<miterlimit>: The limit on the ratio of the miter length to the 'stroke-width'. The value of <miterlimit> must be a number greater than or equal to 1. Any other value shall be treated as unsupported and processed as if the property had not been specified.

The ratio of miter length (distance between the outer tip and the inner corner of the miter) to 'stroke-width' is directly related to the angle (theta) between the segments in user space by the formula:

miterLimit = miterLength / stroke-width = 1 / sin(theta / 2)

For example, a miter limit of 1.414 converts miters to bevels for theta less than 90 degrees, a limit of 4.0 converts them for theta less than approximately 29 degrees, and a limit of 10.0 converts them for theta less than approximately 11.5 degrees.

This property contributes to an element's decorated bounding box.

'stroke-dasharray'

Value:	none \| <list-of-lengths> \| inherit
Initial:	none
Applies to:	shapes and text content elements
Inherited:	yes
Percentages:	N/A
Media:	visual
Animatable:	yes (non-additive)
Computed value:	Specified value, except inherit

'stroke-dasharray' specifies the pattern of dashes and gaps that shall be used to stroke paths. The <list-of-lengths> contains the list of <length>s that specify the lengths of alternating dashes and gaps that must be used. If an odd number of values is provided, then the list of values shall be repeated to yield an even number of values. Thus, stroke-dasharray="5,3,2" is equivalent to stroke-dasharray="5,3,2,5,3,2". The computed value of the attribute 'stroke-linecap' is applied to both sides of each dash. If a dash has zero length, linecaps are still added if the stroke-linecap values round and square are used.

none: Indicates that no dashing shall be used. If stroked, the line must be drawn solid.
<list-of-lengths>: The list of <length>s that specify the lengths of alternating dashes and gaps that must be used. A negative <length> value shall be treated as unsupported and processed as if the property had not been specified. If the sum of the <length>s is zero, then the stroke shall be rendered as if a value of none were specified.

Note: Certain cases regarding the behavior of 'stroke-dasharray' are not fully specified because SVG Tiny implementations often rely on underlying graphics libraries with predetermined behaviors they cannot easily change. Examples include: rendering of 'stroke-linejoin' and 'stroke-linecap' in case a dash ends exactly at a corner of two path segments, continuation of stroke-dasharray in subpaths, and others. These cases may be fully specified in version SVG 1.2 Full. Additional attributes, such as dash-caps that can be defined separately from linecaps may be added. Authors are encouraged not to rely on a specific behavior of a specific viewer for 'stroke-dasharray' regarding these currently unspecified cases.

'stroke-dashoffset'

Value:	<length> \| inherit
Initial:	0
Applies to:	shapes and text content elements
Inherited:	yes
Percentages:	N/A
Media:	visual
Animatable:	yes
Computed value:	Specified value, except inherit

'stroke-dashoffset' specifies the distance into the dash pattern that must be used to start the dash. When rendering a 'path' element with multiple subpaths, the value of 'stroke-dashoffset' should start from scratch with the original value of 'stroke-dashoffset' for each subpath. SVG 1.2 Full may be stricter and also add an additional attribute to change this behavior.

<length>: Values can be negative.

'stroke-opacity'

Value:	<opacity-value> \| inherit
Initial:	1
Applies to:	shapes and text content elements
Inherited:	yes
Percentages:	N/A
Media:	visual
Animatable:	yes
Computed value:	Specified value, except inherit

'stroke-opacity' specifies the opacity of the painting operation used to stroke the current object. (See Painting shapes and text.)

<opacity-value>: The opacity of the painting operation that is to be used to stroke the current object. Any values outside the range 0.0 (fully transparent) to 1.0 (fully opaque) must be clamped to this range. (See Clamping values which are restricted to a particular range.)

Related property: 'fill-opacity'.

11.5 Non-scaling stroke

Sometimes it is of interest to let the outline of an object keep its original width no matter which transforms are applied to it. For example, in a map with a 2px wide line representing roads it is of interest to keep the roads 2px wide even when the user zooms into the map. To achieve this, SVG Tiny 1.2 introduces the 'vector-effect' property. Future versions of the SVG language will allow for more powerful vector effects through this property but this version restricts it to being able to specify the non-scaling stroke behavior.

'vector-effect'

Value:	non-scaling-stroke \| none \| inherit
Initial:	none
Applies to:	graphics elements
Inherited:	no
Percentages:	N/A
Media:	visual
Animatable:	yes
Computed value:	Specified value, except inherit

none: Specifies that no vector effect shall be applied, i.e. the default rendering behaviour from SVG 1.1 is used which is to first fill the geometry of a shape with a specified paint, then stroke the outline with a specified paint.
non-scaling-stroke: Modifies the way an object is stroked. Normally stroking involves calculating stroke outline of the shape's path in current user space and filling that outline with the stroke paint (color or gradient). With the non-scaling-stroke vector effect, stroke outline shall be calculated in the "host" coordinate space instead of user coordinate space. More precisely: a user agent establishes a host coordinate space which in SVG Tiny 1.2 is always the same as "screen coordinate space". The stroke outline is calculated in the following manner: first, the shape's path is transformed into the host coordinate space. Stroke outline is calculated in the host coordinate space. The resulting outline is transformed back to the user coordinate system. (Stroke outline is always filled with stroke paint in the current user space). The resulting visual effect of this modification is that stroke width is not dependant on the transformations of the element (including non-uniform scaling and shear transformations) and zoom level.

Note: Future versions of SVG may allow ways to control the host coordinate system.

Below is an example of the non-scaling-stroke 'vector-effect'.

Example: non-scaling-stroke.svg

<?xml version="1.0"?>
<svg xmlns="http://www.w3.org/2000/svg" version="1.2" baseProfile="tiny"
     width="6cm" height="4cm" viewBox="0 0 600 400" 
     viewport-fill="rgb(255,150,200)">

  <desc>Example non-scaling stroke</desc>
  <rect x="1" y="1" width="598" height="398" fill="none" stroke="black"/>
  
  <g transform="scale(9,1)">
    <line stroke="black" stroke-width="5" x1="10" y1="50" x2="10" y2="350"/>
    <line vector-effect="non-scaling-stroke" stroke="black" stroke-width="5" 
        x1="32" y1="50" x2="32" y2="350"/>
    <line vector-effect="none" stroke="black" stroke-width="5" 
        x1="55" y1="50" x2="55" y2="350"/>
  </g>

</svg>

11.6 Simple alpha compositing

Graphics elements are blended into the elements already rendered on the canvas using simple alpha compositing, in which the resulting color and opacity at any given pixel on the canvas must be the result of the following formulas (all color values use premultiplied alpha):

     Er, Eg, Eb    - Element color value
     Ea            - Element alpha value
     Cr, Cg, Cb    - Canvas color value (before blending)
     Ca            - Canvas alpha value (before blending)
     Cr', Cg', Cb' - Canvas color value (after blending)
     Ca'           - Canvas alpha value (after blending)

     Ca' = 1 - (1 - Ea) * (1 - Ca)
     Cr' = (1 - Ea) * Cr + Er
     Cg' = (1 - Ea) * Cg + Eg
     Cb' = (1 - Ea) * Cb + Eb

The following rendering properties, which provide information about the color space in which to perform the compositing operations, apply to compositing operations:

'color-rendering'

11.6.1 Compositing the currentColor value

The currentColor value may be assigned a color value that has an opacity component. This opacity value is used in the rendering operation using the alpha compositing method described above. That is, the opacity value in currentColor is used when compositing the color into a paint server (which may have its own values for opacity).

11.7 The 'viewport-fill' property

SVG enables the author to specify a solid color which will be used to fill the viewport of any element that creates a viewport, such as the 'svg' element.

The 'viewport-fill' property specifies the color which shall be used to fill the viewport created by a particular element. It must cause the entire canvas of the element that it applies to to be filled with the specified solid color. That canvas may then be clipped by that element's 'viewBox'.

'viewport-fill'

Value:	none \| currentColor \| <color> \| inherit
Initial:	none
Applies to:	viewport-creating elements
Inherited:	no
Percentages:	N/A
Media:	visual
Animatable:	yes
Computed value:	"none" or specified <color> value, except inherit

If the value of 'viewport-fill' is none, then no paint operation is applied to the viewport.

Below is an example of 'viewport-fill'.

Example: 11_02.svg

<?xml version="1.0"?>
<svg xmlns="http://www.w3.org/2000/svg" version="1.2" baseProfile="tiny"
     viewport-fill="red">

  <desc>
    Everything here has a red background.
    The rectangle is not filled, so the red background will show through.
  </desc>

  <rect x="20" y="20" width="100" height="100" fill="none" stroke="black"/>

</svg>

Here is a slightly more complex example. The 'viewBox' gives a coordinate system 300 units wide and 100 units high. The rendering shows what happens when this is displayed inside a square viewport.

Example: 11_03.svg

<?xml version="1.0"?>
<svg xmlns="http://www.w3.org/2000/svg" version="1.2" baseProfile="tiny"
     viewBox="0 0 300 100" viewport-fill="yellow">

  <desc>
    The viewport has a yellow background.
    The rectangle is filled and covers the viewport, so the yellow 
    background will only show through in the "leftovers" if the 
    aspect ratio of the viewport differs from that of the viewBox.
  </desc>

  <rect x="0" y="0" width="300" height="100" fill="red" fill-opacity="0.3" stroke="black"/>

</svg>

The filling of the viewport is the first operation in the rendering chain of an element. Therefore:

The viewport fill operation happens before filling and stroking.
The viewport fill operation occurs before compositing, and thus is part of the input to the compositing operations.
The viewport fill operation renders into the element's conceptual offscreen buffer, and thus opacity applies as usual.
Viewport fill is not affected by the 'fill' or 'fill-opacity' properties.

11.8 The 'viewport-fill-opacity' property

The 'viewport-fill-opacity' property specifies the opacity of the 'viewport-fill' that shall be used for a particular element.

'viewport-fill-opacity'

Value:	<opacity-value> \| inherit
Initial:	1.0
Applies to:	viewport-creating elements
Inherited:	no
Percentages:	N/A
Media:	visual
Animatable:	yes
Computed value:	Specified value, except inherit

<opacity-value>: The opacity of the painting operation that is to be used to fill the viewport. Any values outside the range 0.0 (fully transparent) to 1.0 (fully opaque) must be clamped to this range. (See Clamping values which are restricted to a particular range.)

11.9 Controlling visibility and rendering

SVG uses two properties, 'display' and 'visibility', to control the rendering of graphics elements or (in the case of the 'display' property) container elements. Neither of these two properties affects the objects existence in the DOM, i.e. no matter what value of these properties the object still remains in the DOM.

The differences between the two properties are as follows:

When applied to a container element, setting 'display' to none causes the container and all of its children to be excluded from the rendering tree; thus, it acts on groups of elements as a group. 'visibility', however, only applies to individual graphics elements. Setting 'visibility' to hidden on a 'g' will make its children visually invisible as long as the children do not specify their own 'visibility' properties as visible.
When the 'display' property is set to none, then the given element does not become part of the rendering tree. With 'visibility' set to hidden, however, processing occurs as if the element were part of the rendering tree and still taking up space, but not actually visually rendered onto the canvas. This distinction has implications for the 'tspan' element, event processing, and for bounding box calculations. If 'display' is set to none on a 'tspan' then the text string is ignored for the purposes of text layout; however, if 'visibility' is set to hidden, the text string is used for text layout (i.e., it takes up space) even though it is not visually rendered on the canvas. Regarding events, if 'display' is set to none, the element receives no events which require the element to be in the rendering tree (for example mouse events); however, if 'visibility' is set to hidden, the element might still receive events, depending on the value of property 'pointer-events'. The geometry of a graphics element with 'display' set to none is not included in bounding box calculations; however, even if 'visibility' is to hidden, the geometry of the graphics element still contributes to bounding box calculations.

'display'

Value:	inline \| block \| list-item \| run-in \| compact \| marker \| table \| inline-table \| table-row-group \| table-header-group \| table-footer-group \| table-row \| table-column-group \| table-column \| table-cell \| table-caption \| none \| inherit
Initial:	inline
Applies to:	'svg', 'g', 'switch', 'a', 'foreignObject', graphics elements (including the text content block elements), media elements and text sub-elements (e.g., 'tspan' and 'a')
Inherited:	no
Percentages:	N/A
Media:	all
Animatable:	yes
Computed value:	Specified value, except inherit

A value of display="none" indicates that the given element and its children shall not be rendered directly or made audible (i.e., those elements are not present in the rendering tree). Any computed value other than none indicates that the given element shall be rendered or made audible by the SVG user agent.

The 'display' property only affects the direct rendering or audibility of a given element, whereas it does not prevent elements from being referenced by other elements.

Elements with display="none" do not take up space in text layout operations, do not receive events and do not contribute to bounding box calculations.

Except for any additional information provided in this specification, the normative definition of this property is found in CSS 2 ([CSS2], section 9.2.5).

'visibility'

Value:	visible \| hidden \| collapse \| inherit
Initial:	visible
Applies to:	graphics elements (including the text content block elements), media elements and text sub-elements (e.g., 'tspan' and 'a')
Inherited:	yes
Percentages:	N/A
Media:	all
Animatable:	yes
Computed value:	Specified value, except inherit

visible: The current graphics element or media element shall be visible.
hidden or collapse: The current graphics element or media element shall be invisible (i.e., nothing is painted on the canvas).

Note that, unlike the 'display' property, the 'visibility' property does not have any affect on the audibility of any media element. To control the audibility of an element, use the 'display' or 'audio-level' properties.

Note that if the 'visibility' property is set to hidden on a 'tspan' element, then the text is invisible but shall still takes up space in text layout calculations.

Depending on the value of property 'pointer-events', graphics elements which have their 'visibility' property set to hidden still might receive events.

Except for any additional information provided in this specification, the normative definition of this property is found in CSS 2 ([CSS2], section 11.2).

11.10 Rendering hints

11.10.1 The 'color-rendering' property

The creator of SVG content might want to provide a hint to the implementation about how to make speed versus quality tradeoffs as it performs color interpolation and compositing. The 'color-rendering' property provides a hint to the SVG user agent about how to optimize its color interpolation and compositing operations.

'color-rendering'

Value:	auto \| optimizeSpeed \| optimizeQuality \| inherit
Initial:	auto
Applies to:	container elements, graphics elements and 'animateColor'
Inherited:	yes
Percentages:	N/A
Media:	visual
Animatable:	yes
Computed value:	Specified value, except inherit

auto: Indicates that the user agent shall make appropriate tradeoffs to balance speed and quality, but quality shall be given more importance than speed.
optimizeSpeed: Indicates that the user agent shall emphasize rendering speed over quality. For RGB display devices, this option will sometimes cause the user agent to perform color interpolation and compositing in the device RGB color space.
optimizeQuality: Indicates that the user agent shall emphasize quality over rendering speed.

11.10.2 The 'shape-rendering' property

The creator of SVG content might want to provide a hint to the implementation about what tradeoffs to make as it renders vector graphics elements such as 'path' elements and basic shapes such as circles and rectangles. The 'shape-rendering' property provides these hints.

'shape-rendering'

Value:	auto \| optimizeSpeed \| crispEdges \| geometricPrecision \| inherit
Initial:	auto
Applies to:	shapes
Inherited:	yes
Percentages:	N/A
Media:	visual
Animatable:	yes
Computed value:	Specified value, except inherit

auto: Indicates that the user agent shall make appropriate tradeoffs to balance speed, crisp edges and geometric precision, but with geometric precision given more importance than speed and crisp edges.
optimizeSpeed: Indicates that the user agent shall emphasize rendering speed over geometric precision and crisp edges. This option will sometimes cause the user agent to turn off shape anti-aliasing.
crispEdges: Indicates that the user agent shall attempt to emphasize the contrast between clean edges of artwork over rendering speed and geometric precision. To achieve crisp edges, the user agent might turn off anti-aliasing for all lines and curves or possibly just for straight lines which are close to vertical or horizontal. Also, the user agent might adjust line positions and line widths to align edges with device pixels.
geometricPrecision: Indicates that the user agent shall emphasize geometric precision over speed and crisp edges.

11.10.3 The 'text-rendering' property

The creator of SVG content might want to provide a hint to the implementation about what tradeoffs to make as it renders text. The 'text-rendering' property provides these hints.

'text-rendering'

Value:	auto \| optimizeSpeed \| optimizeLegibility \| geometricPrecision \| inherit
Initial:	auto
Applies to:	text content block elements
Inherited:	yes
Percentages:	N/A
Media:	visual
Animatable:	yes
Computed value:	Specified value, except inherit

auto: Indicates that the user agent shall make appropriate tradeoffs to balance speed, legibility and geometric precision, but with legibility given more importance than speed and geometric precision.
optimizeSpeed: Indicates that the user agent shall emphasize rendering speed over legibility and geometric precision. This option will sometimes cause the user agent to turn off text anti-aliasing.
optimizeLegibility: Indicates that the user agent shall emphasize legibility over rendering speed and geometric precision. The user agent will often choose whether to apply anti-aliasing techniques, built-in font hinting or both to produce the most legible text.
geometricPrecision: Indicates that the user agent shall emphasize geometric precision over legibility and rendering speed. This option will usually cause the user agent to suspend the use of hinting so that glyph outlines are drawn with comparable geometric precision to the rendering of path data.

11.10.4 The 'image-rendering' property

The creator of SVG content might want to provide a hint to the implementation about how to make speed vs. quality tradeoffs as it performs image processing. The 'image-rendering' property provides a hint to the SVG user agent about how to optimize its image rendering.

'image-rendering'

Value:	auto \| optimizeSpeed \| optimizeQuality \| inherit
Initial:	auto
Applies to:	images
Inherited:	yes
Percentages:	N/A
Media:	visual
Animatable:	yes
Computed value:	Specified value, except inherit

auto: Indicates that the user agent shall make appropriate tradeoffs to balance speed and quality, but quality shall be given more importance than speed. The user agent shall employ a resampling algorithm at least as good as nearest neighbor resampling, but bilinear resampling is strongly preferred. For Conforming High-Quality SVG Viewers, the user agent shall employ a resampling algorithm at least as good as bilinear resampling.
optimizeQuality: Indicates that the user agent shall emphasize quality over rendering speed. The user agent shall employ a resampling algorithm at least as good as bilinear resampling.
optimizeSpeed: Indicates that the user agent shall emphasize rendering speed over quality. The user agent should use a resampling algorithm which achieves the goal of fast rendering, with the requirement that the resampling algorithm shall be at least as good as nearest neighbor resampling. If performance goals can be achieved with higher quality algorithms, then the user agent should use the higher quality algorithms instead of nearest neighbor resampling.

In all cases, resampling must be done in a truecolor (e.g., 24-bit) color space even if the original data and/or the target device is indexed color.

11.10.5 The 'buffered-rendering' property

The creator of SVG content might want to provide a hint to the implementation about how often an element is modified to make speed vs. memory tradeoffs as it performs rendering. The 'buffered-rendering' property provides a hint to the SVG user agent about how to buffer the rendering of elements:

'buffered-rendering'

Value:	auto \| dynamic \| static \| inherit
Initial:	auto
Applies to:	container elements and graphics elements
Inherited:	no
Percentages:	N/A
Media:	visual
Animatable:	yes
Computed value:	Specified value, except inherit

auto: Indicates that the user agent is expected to use a reasonable compromise between speed of update and resource allocation.
dynamic: Indicates that the element is expected to be modified often.
static: Indicates that the element is not expected to be modified often. This suggests that user agent may be able to allocate resources, such as an offscreen buffer, that would allow increased performance in redraw. It does not mean that the element will never change. If an element is modified when the value is 'static', then redraw might have reduced performance.

11.11 Inheritance of painting properties

The values of any of the painting properties described in this chapter can be inherited from a given object's parent. Painting, however, is always done on each graphics element individually, never at the container element (e.g., a 'g') level. Thus, for the following SVG, even though the gradient fill is specified on the 'g', the gradient is simply inherited through the 'g' element down into each rectangle, each of which is rendered such that its interior is painted with the gradient.

Example Inheritance

Example: 11_01.svg

<?xml version="1.0"?>
<svg xmlns="http://www.w3.org/2000/svg" version="1.2" baseProfile="tiny"
     width="7cm" height="2cm" viewBox="0 0 700 200">

  <desc>Gradients apply to leaf nodes</desc>

  <g>
    <defs>
      <linearGradient xml:id="MyGradient" gradientUnits="objectBoundingBox">
        <stop offset="0" stop-color="#F60"/>
        <stop offset="1" stop-color="#FF6"/>
      </linearGradient>
    </defs>

    <rect x="1" y="1" width="698" height="198"
          fill="none" stroke="blue" stroke-width="2"/>

    <g fill="url(#MyGradient)">
      <rect x="100" y="50" width="200" height="100"/>
      <rect x="400" y="50" width="200" height="100"/>
   </g>
  </g>
</svg>

Any painting properties defined in terms of the object's bounding box use the bounding box of the graphics element to which the operation applies. Note that text elements are defined such that any painting operations defined in terms of the object's bounding box use the bounding box of the entire 'text' element. (See the discussion of object bounding box units and text elements.)

11.12 Object and group opacity: the 'opacity' property

There are several opacity properties within SVG:

Solid color opacity
Fill opacity
Stroke opacity
Gradient stop opacity
Viewport fill opacity
Object/group opacity (described here)

Except for object/group opacity (described just below), all other opacity properties are involved in intermediate rendering operations. Object/group opacity can be thought of conceptually as a postprocessing operation. Conceptually, after the object/group is rendered into an RGBA offscreen image, the object/group opacity setting specifies how to blend the offscreen image into the current background.

Object/group opacity can, if applied to container elements, be a resource intensive operation. Therefore this version of SVG restricts this property to only be set on, and only apply to, the 'image' element. Note: if the value is set to inherit, then the initial value of 1 for the opacity property will be used, meaning full opacity. This is the same as not specifying it at all.

'opacity'

Value:	<opacity-value> \| inherit
Initial:	1
Applies to:	'image' element
Inherited:	no
Percentages:	N/A
Media:	visual
Animatable:	yes
Computed value:	Specified value, except inherit

<opacity-value>: The uniform opacity setting that must applied across an entire object. Any values outside the range 0.0 (fully transparent) to 1.0 (fully opaque) must be clamped to this range. (See Clamping values which are restricted to a particular range.)

Below is an example of 'opacity' which illustrates the difference in behavior between SVG Basic/Full 1.1 and SVG Tiny 1.2.

Example: struct-image-201-t.svg

<?xml version="1.0" encoding="UTF-8"?>
<svg version="1.2" baseProfile="tiny" xml:id="svg-root" width="100%" height="100%" 
  viewBox="0 0 480 360" xmlns="http://www.w3.org/2000/svg" xmlns:ev="http://www.w3.org/2001/xml-events"
  xmlns:xlink="http://www.w3.org/1999/xlink">
  <!--======================================================================-->
  <!--=  Copyright 2007 World Wide Web Consortium, (Massachusetts          =-->
  <!--=  Institute of Technology, European Research Consortium for         =-->
  <!--=  Informatics and Mathematics (ERCIM), Keio University).            =-->
  <!--=  All Rights Reserved.                                              =-->
  <!--=  See http://www.w3.org/Consortium/Legal/.                          =-->
  <!--======================================================================-->
  <metadata>
      <p>
        This test shows the differences in opacity-handling between SVG Tiny 1.2 and SVG Full 1.1.
      </p>
	  <p>
		The test has passed if the leftmost column looks like either of the other two columns. 
		SVG Tiny 1.2 requires only what is portrayed by the middle column, but does not require 
		user agents that implement both SVG 1.1 and 1.2 Tiny to follow the more limited 
		opacity-handling in 1.2 Tiny.
	  </p>
	  <p>
		In SVG Tiny 1.2 the opacity property is only allowed on the image element itself. 
		If it's encountered anywhere else it must be treated as an unsupported value.

		NOTE: This test is not valid 1.2 Tiny because it's using opacity on something 
		other than the image element.
	  </p>
</metadata>
  <title xml:id="test-title">&#36;RCSfile: struct-image-201-t.svg,v $</title>
  <defs>
    <font-face
      font-family="SVGFreeSansASCII"
      unicode-range="U+0-7F">
      <font-face-src>
        <font-face-uri xlink:href="SVGFreeSans.svg#ascii"/>
      </font-face-src>
    </font-face>
  </defs>
  <g xml:id="test-body-content" font-family="SVGFreeSansASCII,sans-serif" font-size="18">
	
	<text x="240" y="70" text-anchor="middle" font-size="32">Test opacity</text>
	
	<g id="test" transform="translate(-100 0)">
		<text x="240" y="120" text-anchor="middle">Test</text>
		<text x="240" y="130" text-anchor="middle" font-size="9">Mouseover to compare</text>
		<rect id="r1" x="200" y="135" height="20" width="80" fill="green"/>
		<rect id="r2" x="200" y="160" height="20" width="80" fill="green"/>
		<rect id="r3" x="200" y="185" height="20" width="80" fill="green"/>
		<rect id="r4" x="200" y="210" height="20" width="80" fill="green"/>
		
		<g pointer-events="none">
			<image width="460" height="20" x="10" y="135" xlink:href="1pixelwhite.png" preserveAspectRatio="none" opacity="0.25"/>
			<g opacity="0.5">
				<image width="460" height="20" x="10" y="160" xlink:href="1pixelwhite.png" preserveAspectRatio="none" opacity="0.5"/>
				<rect id="r5" x="200" y="185" height="20" width="80" fill="white" opacity="0.5"/>
				
			</g>
			<g opacity="0.75">
				<g opacity="inherit">
					<image width="460" height="20" x="10" y="210" xlink:href="1pixelwhite.png" preserveAspectRatio="none" opacity="inherit"/>
				</g>
			</g>
		</g>
		
		<ev:listener event="mouseover" observer="r1" handler="#handler"/>
		<ev:listener event="mouseout" observer="r1" handler="#handler"/>
		<ev:listener event="mouseover" observer="r2" handler="#handler"/>
		<ev:listener event="mouseout" observer="r2" handler="#handler"/>
		<ev:listener event="mouseover" observer="r3" handler="#handler"/>
		<ev:listener event="mouseout" observer="r3" handler="#handler"/>
		<ev:listener event="mouseover" observer="r4" handler="#handler"/>
		<ev:listener event="mouseout" observer="r4" handler="#handler"/>
		<handler id="handler">
			if(event.type == "mouseover")
			{
				event.target.setFloatTrait("width", 280);
				if(event.target.id == "r3")
					document.getElementById("r5").setFloatTrait("width", 280);
			}
			else
			{
				event.target.setFloatTrait("width", 80);
				if(event.target.id == "r3")
					document.getElementById("r5").setFloatTrait("width", 80);
			}
		</handler>
	</g>
	
	<g id="tiny12reference">
		<text x="240" y="120" text-anchor="middle">Tiny 1.2 ref</text>
		<rect x="200" y="135" height="20" width="80" fill="green"/>
		<rect x="200" y="160" height="20" width="80" fill="green"/>
		<rect x="200" y="185" height="20" width="80" fill="green"/>
		<rect x="200" y="210" height="20" width="80" fill="green"/>
		<rect x="200" y="135" height="20" width="80" fill="white" fill-opacity="0.25"/>
		<rect x="200" y="160" height="20" width="80" fill="white" fill-opacity="0.5"/>
		<rect x="200" y="185" height="20" width="80" fill="white" fill-opacity="1"/>
		<rect x="200" y="210" height="20" width="80" fill="white" fill-opacity="1"/>
	</g>
	
	<g id="full11reference" transform="translate(100 0)">
		<text x="240" y="120" text-anchor="middle">Full 1.1 ref</text>
		<rect x="200" y="135" height="20" width="80" fill="green"/>
		<rect x="200" y="160" height="20" width="80" fill="green"/>
		<rect x="200" y="185" height="20" width="80" fill="green"/>
		<rect x="200" y="210" height="20" width="80" fill="green"/>
		<rect x="200" y="135" height="20" width="80" fill="white" fill-opacity="0.25"/>
		<rect x="200" y="160" height="20" width="80" fill="white" fill-opacity="0.25"/>
		<rect x="200" y="185" height="20" width="80" fill="white" fill-opacity="0.25"/>
		<rect x="200" y="210" height="20" width="80" fill="white" fill-opacity="0.421875"/>
	</g>
	
  </g>
  <g font-family="SVGFreeSansASCII,sans-serif" font-size="32">
  <text xml:id="revision" x="10" y="340" stroke="none" 
    fill="black">&#36;Revision: 1.4 $</text>
  </g>
  <rect xml:id="test-frame" x="1" y="1" width="478" height="358" fill="none" stroke="#000"/>
</svg>

11.13 Color

In SVG Tiny 1.2, all colors are specified in the sRGB color space [SRGB]. SVG Tiny 1.2 user agents are not required to, but may, support color management. However, SVG Tiny 1.2 user agents should apply gamma correction if the response curve of the display system differs from that of sRGB.

11.13.1 Syntax for color values

Five syntactical forms are specified for SVG Tiny 1.2, and all of them must be supported in a conforming SVG Interpreter:

Three digit hex — #rgb: Each hexadecimal digit, in the range 0 to F, represents one sRGB color component in the order red, green and blue. The digits A to F may be in either uppercase or lowercase. The value of the color component is obtained by replicating digits, so 0 become 00, 1 becomes 11, F becomes FF. This compact syntactical form can represent only 4096 colors. Examples: #000 (i.e. black) #fff (i.e. white) #6CF (i.e. #66CCFF, rgb(102, 204, 255)).
Six digit hex — #rrggbb: Each pair of hexadecimal digits, in the range 0 to F, represents one sRGB color component in the order red, green and blue. The digits A to F may be in either uppercase or lowercase.This syntactical form, originally introduced by HTML, can represent 16777216 colors. Examples: #9400D3 (i.e. a dark violet), #FFD700 (i.e. a golden color).
Integer functional — rgb(rrr, ggg, bbb): Each integer represents one sRGB color component in the order red, green and blue, separated by a comma and optionally by white space. Each integer is in the range 0 to 255. This syntactical form can represent 16777216 colors. Examples: rgb(233, 150, 122) (i.e. a salmon pink), rgb(255, 165, 0) (i.e. an orange).
Float functional — rgb(R%, G%, B%): Each percentage value represents one sRGB color component in the order red, green and blue, separated by a comma and optionally by white space. For colors inside the sRGB gamut, the range of each component is 0.0% to 100.0% and an arbitrary number of decimal places may be supplied. Scientific notation is not supported. This syntactical form can represent an arbitrary range of colors, completely covering the sRGB gamut. Color values where one or more components are below 0.0% or above 100.0% represent colors outside the sRGB gamut Examples: rgb(12.375%, 34.286%, 28.97%).
Color keyword: The sixteen color keywords below (originally from HTML 4 [HTML4]) must be supported, with the further restriction that they must be lowercase.

11.13.2 HTML color keywords

black	rgb(0, 0, 0)	green	rgb(0, 128, 0)
silver	rgb(192, 192, 192)	lime	rgb(0, 255, 0)
gray	rgb(128, 128, 128)	olive	rgb(128, 128, 0)
white	rgb(255, 255, 255)	yellow	rgb(255, 255, 0)
maroon	rgb(128, 0, 0)	navy	rgb(0, 0, 128)
red	rgb(255, 0, 0)	blue	rgb(0, 0, 255)
purple	rgb(128, 0, 128)	teal	rgb(0, 128, 128)
fuchsia	rgb(255, 0, 255)	aqua	rgb(0, 255, 255)

11.14 Paint servers

With SVG, you can fill (i.e., paint the interior of) or stroke (i.e., paint the outline of) shapes and text using one of the following:

color (using <color> or a reference to a 'solidColor' element)
a system paint
gradients (linear or radial)

SVG uses the general notion of a paint server. Gradients and patterns are just specific types of built-in paint servers. The 'solidColor' element is another built-in paint server, described in Color.

Apart from system paint, paint servers are referenced using a local IRI reference on a 'fill' or 'stroke' property.

11.14.1 System paint servers

The following list of system paint servers must be supported. If a paint specification specifies one of the system paint servers, then the user agent must either paint using a system-provided paint server or paint with a substitute paint server, such as a color or gradient. System paint servers often depend on the operating system, user choices, and the implementation. Substitute paint servers should attempt to match the appearance of corresponding user interface elements on the platform, including user color choices. In environments which do not provide adequate system paint server APIs, a conformant user agent may use substitute paint servers which do not necessarily match the environment's system paint servers.

The computed value of a paint specified as a system paint is the specified value.

ActiveBorder: Active window border.
ActiveCaption: Active window caption.
AppWorkspace: Background color of multiple document interface.
Background: Desktop background.
ButtonFace: Face color for three-dimensional display elements.
ButtonHighlight: Dark shadow for three-dimensional display elements (for edges facing away from the light source).
ButtonShadow: Shadow color for three-dimensional display elements.
ButtonText: Text on push buttons.
CaptionText: Text in caption, size box, and scrollbar arrow box.
GrayText: Disabled ('grayed') text.
Highlight: Item(s) selected in a control.
HighlightText: Text of item(s) selected in a control.
InactiveBorder: Inactive window border.
InactiveCaption: Inactive window caption.
InactiveCaptionText: Color of text in an inactive caption.
InfoBackground: Background color for tooltip controls.
InfoText: Text color for tooltip controls.
Menu: Menu background.
MenuText: Text in menus.
Scrollbar: Scroll bar gray area.
ThreeDDarkShadow: Dark shadow for three-dimensional display elements.
ThreeDFace: Face color for three-dimensional display elements.
ThreeDHighlight: Highlight color for three-dimensional display elements.
ThreeDLightShadow: Light color for three-dimensional display elements (for edges facing the light source).
ThreeDShadow: Dark shadow for three-dimensional display elements.
Window: Window background.
WindowFrame: Window frame.
WindowText: Text in windows.

11.14.2 The 'solidColor' element

The 'solidColor' element is a paint server that provides a single color with opacity. It can be referenced like the other paint servers (i.e. gradients).

Schema: solidColor

    <define name='solidColor'>
      <element name='solidColor'>
        <ref name='solidColor.AT'/>
        <ref name='solidColor.CM'/>
      </element>
    </define>

    <define name='solidColor.CM'>
      <zeroOrMore>
        <choice>
          <ref name='svg.Desc.group'/>
          <ref name='svg.Animate.group'/>
          <ref name='svg.Handler.group'/>
          <ref name='svg.Discard.group'/>
        </choice>
      </zeroOrMore>
    </define>

    <define name='solidColor.AT' combine='interleave'>
      <ref name='svg.Properties.attr'/>
      <ref name='svg.Core.attr'/>
    </define>

The 'solid-color' property specifies the color that shall be used for this 'solidColor' element. The keyword currentColor can be specified in the same manner as within a <paint> specification for the 'fill' and 'stroke' properties.

'solid-color'

Value:	currentColor \| <color> \| inherit
Initial:	black
Applies to:	'solidColor' elements
Inherited:	no
Percentages:	N/A
Media:	visual
Animatable:	yes
Computed value:	Specified <color> value, except inherit

The 'solid-opacity' property defines the opacity of the 'solidColor'.

'solid-opacity'

Value:	<opacity-value> \| inherit
Initial:	1
Applies to:	'solidColor' elements
Inherited:	no
Percentages:	N/A
Media:	visual
Animatable:	yes
Computed value:	Specified value, except inherit

<opacity-value>: The opacity of the 'solidColor'. Any values outside the range 0.0 (fully transparent) to 1.0 (fully opaque) must be clamped to this range. (See Clamping values which are restricted to a particular range.)

The 'solidColor' paint server applies paint of the specified color using the opacity defined in 'solid-opacity'. The value of 'solid-opacity' is independent of the opacity used to render the paint via 'fill' or 'stroke' (see alpha compositing).

Properties shall inherit into the 'solidColor' element from its ancestors; properties shall not inherit from the element referencing the 'solidColor' element.

'solidColor' elements are never rendered directly; their only usage is as something that can be referenced using the 'fill' and 'stroke' properties. The 'display' property does not apply to the 'solidColor' element; thus, 'solidColor' elements are not directly rendered even if the 'display' property is set to a value other than none, and 'solidColor' elements are available for referencing even when the 'display' property on the 'solidColor' element or any of its ancestors is set to none.

Below is an example of the 'solidColor' element:

Example: solidcolor.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="1.2" baseProfile="tiny"
     width="480" height="360" viewBox="0 0 480 360">

  <title>'solidColor' example</title>

  <defs>
    <solidColor xml:id="solidMaroon" solid-color="maroon" solid-opacity="0.7"/>
  </defs>

  <g>
    <circle transform="translate(100, 150)" fill="url(#solidMaroon)" r="30"/>
    <rect fill="url(#solidMaroon)" transform="translate(190, 150)" x="-30" y="-30" width="60" height="60"/>
    <path fill="url(#solidMaroon)" transform="translate(270, 150)"  d="M 0 -30 L 30 30 L -30 30 Z" />
    <text fill="url(#solidMaroon)" transform="translate(340, 150)" y="21" font-weight="bold" font-size="60">A</text>
  </g>
</svg>

11.14.3 The 'color' property

The 'color' property, which is defined in CSS2 as the color of text, does not directly apply to SVG elements. The value of the SVG color property may however be used to provide an indirect value for those properties which allow the currentColor keyword: the 'fill', 'stroke', 'solid-color' and 'stop-color' properties.

'color'

Value:	<color> \| inherit
Initial:	depends on user agent
Applies to:	None. Indirectly affects other properties via currentColor
Inherited:	yes
Percentages:	N/A
Media:	visual
Animatable:	yes
Computed value:	Specified <color> value, except inherit

Except for any additional information provided in this specification, the normative definition of the property is found in CSS 2 ([CSS2], section 14.1).

11.15 Gradients

Gradients consist of continuously smooth color transitions along a vector from one color to another, possibly followed by additional transitions along the same vector to other colors. SVG provides for two types of gradients, 'linearGradient' and 'radialGradient'.

Once defined, gradients are then referenced using 'fill' or 'stroke' properties on a given graphics element to indicate that the given element shall be filled or stroked with the referenced gradient.

11.15.1 Linear gradients

Linear gradients are defined by a 'linearGradient' element.

Schema: linearGradient

    <define name='linearGradient'>
      <element name='linearGradient'>
        <ref name='linearGradient.AT'/>
        <ref name='GradientCommon.CM'/>
      </element>
    </define>

    <define name='linearGradient.AT' combine='interleave'>
      <ref name='svg.Properties.attr'/>
      <ref name='svg.GradientCommon.attr'/>
      <ref name='svg.Core.attr'/>
      <ref name='svg.X12Y12.attr'/>
    </define>

Attribute definitions:

gradientUnits = "userSpaceOnUse" | "objectBoundingBox"

Defines the coordinate system for attributes 'x1', 'y1', 'x2', 'y2' that shall be used when rendering the gradient.

If gradientUnits="userSpaceOnUse", 'x1', 'y1', 'x2', 'y2' shall represent values in the coordinate system that results from taking the current user coordinate system in place at the time when the gradient element is referenced (i.e., the user coordinate system for the element referencing the gradient element via a 'fill' or 'stroke' property).

If gradientUnits="objectBoundingBox", the user coordinate system for attributes 'x1', 'y1', 'x2', 'y2' shall be established using the bounding box of the element to which the gradient is applied (see Object bounding box units).

When gradientUnits="objectBoundingBox" the stripes of the linear gradient shall be perpendicular to the gradient vector in object bounding box space (i.e., the abstract coordinate system where (0,0) is at the top/left of the object bounding box and (1,0) is at the top/right of the object bounding box). When the object's bounding box is not square, the stripes that are conceptually perpendicular to the gradient vector within object bounding box space shall render non-perpendicular relative to the gradient vector in user space due to application of the non-uniform scaling transformation from bounding box space to user space.

The lacuna value is 'objectBoundingBox'.

Animatable: yes.

x1 = "<coordinate>"

'x1', 'y1', 'x2', 'y2' define a gradient vector for the linear gradient. This gradient vector provides starting and ending points onto which the gradient stops shall be mapped. The values of 'x1', 'y1', 'x2', 'y2' must be numbers.

The lacuna value is '0'.

Animatable: yes.

y1 = "<coordinate>"

See 'x1'.

The lacuna value is '0'.

Animatable: yes.

x2 = "<coordinate>"

See 'x1'.

The lacuna value is '1'.

Animatable: yes.

y2 = " <coordinate>"

See 'x1'.

The lacuna value is '0'.

Animatable: yes.

If 'x1' = 'x2' and 'y1' = 'y2', then the area to be painted shall be painted as a single color using the color and opacity of the last gradient stop.

If the gradient starts or ends inside the bounds of the target rectangle the terminal colors of the gradient shall be used to fill the remainder of the target region.

Properties shall inherit into the 'linearGradient' element from its ancestors; properties shall not inherit from the element referencing the 'linearGradient' element.

'linearGradient' elements are never rendered directly; their only usage is as something that can be referenced using the 'fill' and 'stroke' properties. The 'display' property does not apply to the 'linearGradient' element; thus, 'linearGradient' elements are not directly rendered even if the 'display' property is set to a value other than none, and 'linearGradient' elements are available for referencing even when the 'display' property on the 'linearGradient' element or any of its ancestors is set to none.

Example 13_01 shows how to fill a rectangle by referencing a linear gradient paint server.

Example: 13_01.svg

<?xml version="1.0"?>
<svg xmlns="http://www.w3.org/2000/svg" version="1.2" baseProfile="tiny"
     width="8cm" height="4cm" viewBox="0 0 800 400">

  <desc>Example 13_01 - fill a rectangle using a linear gradient paint server</desc>

  <g>
    <defs>
      <linearGradient xml:id="MyGradient">
        <stop offset="0.05" stop-color="#F60"/>
        <stop offset="0.95" stop-color="#FF6"/>
      </linearGradient>
    </defs>

    <!-- Outline the drawing area in blue -->
    <rect fill="none" stroke="blue" 
          x="1" y="1" width="798" height="398"/>

    <!-- The rectangle is filled using a linear gradient paint server -->
    <rect fill="url(#MyGradient)" stroke="black" stroke-width="5"  
          x="100" y="100" width="600" height="200"/>
  </g>
</svg>

11.15.2 Radial gradients

Radial gradients are defined by a 'radialGradient' element.

Schema: radialGradient

    <define name='radialGradient'>
      <element name='radialGradient'>
        <ref name='radialGradient.AT'/>
        <ref name='GradientCommon.CM'/>
      </element>
    </define>

    <define name='radialGradient.AT' combine='interleave'>
      <ref name='svg.Properties.attr'/>
      <ref name='svg.GradientCommon.attr'/>
      <ref name='svg.Core.attr'/>
      <ref name='svg.CxCy.attr'/>
      <ref name='svg.R.attr'/>
    </define>

Attribute definitions:

gradientUnits = "userSpaceOnUse" | "objectBoundingBox"

Defines the coordinate system for attributes 'cx', 'cy', 'r' that shall be used when rendering the gradient.

If gradientUnits="userSpaceOnUse", 'cx', 'cy', 'r' shall represent values in the coordinate system that results from taking the current user coordinate system in place at the time when the gradient element is referenced (i.e., the user coordinate system for the element referencing the gradient element via a 'fill' or 'stroke' property).

If gradientUnits="objectBoundingBox", the user coordinate system for attributes 'cx', 'cy', 'r' shall be established using the bounding box of the element to which the gradient is applied (see Object bounding box units).

When gradientUnits="objectBoundingBox" the rings of the radial gradient shall be circular with respect to the object bounding box space (i.e., the abstract coordinate system where (0,0) is at the top/left of the object bounding box and (1,1) is at the bottom/right of the object bounding box). When the object's bounding box is not square, the rings that are conceptually circular within object bounding box space shall render as elliptical due to application of the non-uniform scaling transformation from bounding box space to user space.

The lacuna value is 'objectBoundingBox'.

Animatable: yes.

cx = "<coordinate>"

'cx', 'cy' and 'r' define the largest (i.e., outermost) circle for the radial gradient and the 0 gradient stop is mapped to ('cx', 'cy').

The lacuna value is '0.5'.

Animatable: yes.

cy = "<coordinate>"

See 'cx'.

The lacuna value is '0.5'.

Animatable: yes.

r = "<length>"

See 'cx'.

A negative value shall be treated as unsupported. A value of zero shall cause the area to be painted as a single color using the color and opacity of the last gradient stop. The lacuna value is '0.5'.

Animatable: yes.

If the gradient starts or ends inside the bounds of the object(s) being painted by the gradient the terminal colors of the gradient shall be used to fill the remainder of the target region.

Properties shall inherit into the 'radialGradient' element from its ancestors; properties shall not inherit from the element referencing the 'radialGradient' element.

'radialGradient' elements must never be rendered directly; their only usage is as something that can be referenced using the 'fill' and 'stroke' properties. The 'display' property does not apply to the 'radialGradient' element; thus, 'radialGradient' elements are not directly rendered even if the 'display' property is set to a value other than none, and 'radialGradient' elements are available for referencing even when the 'display' property on the 'radialGradient' element or any of its ancestors is set to none.

Example 13_02 shows how to fill a rectangle by referencing a radial gradient paint server.

Example: 13_02.svg

<?xml version="1.0"?>
<svg xmlns="http://www.w3.org/2000/svg" version="1.2" baseProfile="tiny"
     width="8cm" height="4cm" viewBox="0 0 800 400">

  <desc>Example 13_02 - fill a rectangle by referencing a radial gradient paint server</desc>

  <g>
    <defs>
      <radialGradient xml:id="MyGradient" gradientUnits="userSpaceOnUse"
                      cx="400" cy="200" r="300">
        <stop offset="0" stop-color="red"/>
        <stop offset="0.5" stop-color="blue"/>
        <stop offset="1" stop-color="red"/>
      </radialGradient>
    </defs>

    <!-- Outline the drawing area in blue -->
    <rect fill="none" stroke="blue" 
          x="1" y="1" width="798" height="398"/>

    <!-- The rectangle is filled using a radial gradient paint server -->
    <rect fill="url(#MyGradient)" stroke="black" stroke-width="5"  
          x="100" y="100" width="600" height="200"/>
  </g>
</svg>

11.15.3 Defining gradient stops: the 'stop' element

The ramp of colors to use on a gradient is defined by the 'stop' elements that are child elements to either the 'linearGradient' element or the 'radialGradient' element.

Schema: stop

    <define name='stop'>
      <element name='stop'>
        <ref name='stop.AT'/>
        <ref name='stop.CM'/>
      </element>
    </define>

    <define name='stop.CM'>
      <zeroOrMore>
        <choice>
          <ref name='svg.Desc.group'/>
          <ref name='svg.Animate.group'/>
        </choice>
      </zeroOrMore>
    </define>

    <define name='stop.AT' combine='interleave'>
      <ref name='svg.Properties.attr'/>
      <ref name='svg.Core.attr'/>
      <optional>
        <attribute name='offset' svg:animatable='true' svg:inheritable='false'>
          <ref name='Number.datatype'/>
        </attribute>
      </optional>
    </define>

Attribute definitions:

offset = "<number>"

The 'offset' attribute is a <number> which indicates where the gradient stop shall be placed. For linear gradients, the 'offset' attribute represents a location along the gradient vector. For radial gradients, it represents a relative distance from ('cx', 'cy') to the edge of the outermost/largest circle.

The lacuna value is '0'.

Animatable: yes.

The 'stop-color' property specifies the color that shall be used at the gradient stop. The keyword currentColor can be specified in the same manner as within a <paint> specification for the 'fill' and 'stroke' properties.

'stop-color'

Value:	currentColor \| <color> \| inherit
Initial:	black
Applies to:	'stop' elements
Inherited:	no
Percentages:	N/A
Media:	visual
Animatable:	yes
Computed value:	Specified <color> value, except inherit

The 'stop-opacity' property specifies the opacity that shall be used for the gradient 'stop'.

'stop-opacity'

Value:	<opacity-value> \| inherit
Initial:	1
Applies to:	'stop' elements
Inherited:	no
Percentages:	N/A
Media:	visual
Animatable:	yes
Computed value:	Specified value, except inherit

The gradient paint server applies paint of the specified gradient using the opacities defined by 'stop-opacity' values. The values of 'stop-opacity' are independent of the opacity used to render the paint via 'fill' or 'stroke' (see alpha compositing).

<opacity-value>: The opacity of the 'stop-color' for the current gradient 'stop'. Any values outside the range 0.0 (fully transparent) to 1.0 (fully opaque) must be clamped to this range. (See Clamping values which are restricted to a particular range.)

Some notes on gradients:

Any gradient offset values outside the range 0.0 to 1.0 must be clamped to this range. (See Clamping values which are restricted to a particular range.)
It is necessary that at least two 'stop' elements are specified to have a gradient effect. If no 'stop' elements are specified, then painting shall occur as if none were specified as the paint style. If one 'stop' is specified, then painting shall occur with the solid color fill using the color defined for that gradient stop.
Each gradient offset value is required to be equal to or greater than the previous gradient stop's offset value. If a given gradient stop's offset value is not equal to or greater than all previous offset values, then the offset value must be adjusted to be equal to the largest of all previous offset values.
If two gradient stops have the same offset value, then the latter gradient stop shall control the color value at the overlap point. In particular:
```
<stop offset="0" stop-color="white"/>
<stop offset=".2" stop-color="red"/>
<stop offset=".2" stop-color="blue"/>
<stop offset="1" stop-color="black"/>
```
will have approximately the same effect as:
```
<stop offset="0" stop-color="white"/>
<stop offset=".1999999999" stop-color="red"/>
<stop offset=".2" stop-color="blue"/>
<stop offset="1" stop-color="black"/>
```
which is a gradient that goes smoothly from white to red, then abruptly shifts from red to blue, and then goes smoothly from blue to black.
Colors and opacities are interpolated separately, and the resulting gradient is composited using simple alpha compositing. In particular:
```
<stop offset="0" stop-color="#F00" stop-opacity="0"/>
<stop offset="1" stop-color="#0F0" stop-opacity="1"/>
```
will produce a gradient from fully transparent red, via partly transparent dark yellow, to fully opaque lime.
All gradient stops must be converted into the interpolation color space. Interpolation between gradient stop colors must occur in the interpolation color space.
SVG Tiny 1.2 user agents have the option to interpolate gradients in either sRGB or in linearRGB color space. Both color spaces have the same color gamut (see [SRGB]).
Other W3C specifications may allow alternative interpolation color spaces to be specified.

12 Multimedia

12.1 Media elements
- 12.1.1 Media timeline and document timeline
- 12.1.2 Media availability
- 12.1.3 Platform limits
- 12.1.4 Audio mixing for 'audio' and 'video' elements
- 12.1.5 Discrete control of audio and video
- 12.1.6 Controlling media playback through script
12.2 The 'audio' element
12.3 The 'video' element
- 12.3.1 Restricting the transformation of the 'video' element
- 12.3.2 Restricting compositing of the 'video' element
- 12.3.3 Examples
12.4 The 'animation' element
12.5 The 'audio-level' property
12.6 Attributes for runtime synchronization
12.7 The 'initialVisibility' attribute

12.1 Media elements

SVG supports media elements similar to the SMIL 2.1 Media Elements ([SMIL21], chapter 7). Media elements define their own timelines within their time container. All SVG media elements support the SVG timing attributes and runtime synchronization attributes. The default event-base element for all SVG media elements is the element itself.

The following elements are media elements:

'audio'
'video'
'animation'

12.1.1 Media timeline and document timeline

Media elements start playing when they become active, i.e. at a time specified in the document timeline which depends on their 'begin' attribute (see SVG timing attributes). However, depending on the value of the 'timelineBegin' attribute on the rootmost 'svg' element, the actual beginning of the document timeline may be delayed until the whole document is loaded. This is the case when 'timelineBegin' is set to 'onLoad'. In that case, the beginning of the actual playback of the media will be delayed, but the media begin time in the document timeline will remain as specified.

Note: 'image' elements are not considered as media elements because they are not timed. They start playing at time 0 in the document timeline.

The following examples illustrate this behavior:

Example: video-timelineBegin-01.svg

<?xml version="1.0"?>
<svg xml:id="A" xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink" version="1.2" baseProfile="tiny" 
            timelineBegin="onLoad">          <!-- process time = t0 -->
<!-- ...[many elements]... -->               <!-- additional process time = t1 = 5s -->
<video xlink:href="myvideo.mp4" begin="0s"/> <!-- additional process time = t2 = 1s -->
</svg>

In this example, the document timeline will start after the document is fully processed, i.e. at time t0+t1+t2 ≥ 6s. The video will start when the document is loaded. But, at that time, the document time will be 0. So, the video will start with the first frame of the video.

Example: video-timelineBegin-02.svg

<?xml version="1.0"?>
<svg xml:id="B" xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink" version="1.2" baseProfile="tiny" 
            timelineBegin="onStart">         <!-- process time = t0 -->
<!-- ...[many elements]... -->               <!-- additional process time = t1 = 5s -->
<video xlink:href="myvideo.mp4" begin="0s"/> <!-- additional process time = t2 = 1s -->
</svg>

In this example, the document timeline will start when the 'svg' element is fully parsed and processed, i.e. at time t0. The video will also start at document time 0, but since the video will only be processed when document time is t0+t1+t2, the video will start displaying the frame at time t0+t1+t2 in the video timeline.

Furthermore, the time in the media timeline which is played, e.g. the exact frame of video or the exact sample of audio that is played, can be altered by the 'syncBehavior' attribute. The following examples illustrate this behavior. These examples are the same as the previous ones, but the values of the 'syncBehavior' attributes are changed from the default value to 'independent'.

Example: video-timelineBegin-03.svg

<?xml version="1.0"?>
<svg xml:id="A" xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink" version="1.2" baseProfile="tiny" 
            timelineBegin="onLoad">          <!-- process time = t0 -->
<!-- ...[many elements]... -->               <!-- additional process time = t1 = 5s -->
<video xlink:href="myvideo.mp4" begin="0s" syncBehavior="independent"/> <!-- additional process time = t2 = 1s -->
</svg>

Example: video-timelineBegin-04.svg

<?xml version="1.0"?>
<svg xml:id="B" xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink" version="1.2" baseProfile="tiny" 
            timelineBegin="onStart">         <!-- process time = t0 -->
<!-- ...[many elements]... -->               <!-- additional process time = t1 = 5s -->
<video xlink:href="myvideo.mp4" begin="0s" syncBehavior="independent"/> <!-- additional process time = t2 = 1s -->
</svg>

In example video-timelineBegin-03.svg, the video does not start until the document's load event, whereas in example video-timelineBegin-04.svg, the video begins as soon as the video element is parsed and the video is ready for rendering. In both cases, since the timeline of the document and of the video are independent, when the video will start, it will start from the first frame, i.e. time 0 in the media timeline.

12.1.2 Media availability

The value of the 'externalResourcesRequired' attribute may also delay the actual time at which a media (even images) will start playing, but it does not affect the time in the document timeline. Indeed, media elements and the image element may require external resources referenced by the 'xlink:href' attribute. If the 'externalResourcesRequired' attribute is set to 'true', on the resource or on a parent in the scene tree, e.g. a 'g' element, then this external resource has to become available before the media can start. If the 'externalResourcesRequired' attribute is set to 'false', the media element or the image element will start playing as soon as it becomes active.

The meaning of "available" depends on the media type, on the protocol used to access the resource as well as on the implementation. For example, if a protocol like HTTP is used, "available" may mean that the whole resource is downloaded. It may also mean that a coarse version of the resource is available, for example in case of progressive PNG (see PNG Pass extraction ([PNG], section 4.5.2)). In that case, it is an implementation choice to decide whether to display the coarse version before the whole resource is downloaded. Another example is when streaming protocols like RTSP/RTP are used. In that case, "available" usually means that enough stream has been buffered before the playback may start. To reduce the amount of time required for a media to become available, authors are encouraged to use the 'prefetch' element to signal that external resources have to be prefetched.

12.1.3 Platform limits

Particular platforms may have restrictions on the number of audio voices or channels that can be mixed, or the number of video streams that may be presented concurrently. Since these vary, the SVG language itself does not impose any such limits on audio or video.

12.1.4 Audio mixing for 'audio' and 'video' elements

If two or more audio streams from 'audio' or 'video' elements are active at the same time, their rendering should be mixed in proportions equal to the computed value of the 'audio-level' property of each audio stream. An audio stream may be active if it is referred to by an active audio element or if it is part of video content that is referred to by an active 'video' element.

12.1.5 Discrete control of audio and video

Authors may wish to independently control both the visual and auditory aspects of the 'video' element. Through a combination of the various properties available, all permutations are possible, as described below:

play both video and audio: this is the default setting, and nothing special needs to be done
play video with no audio: use the 'audio-level' property with a value of 0
play audio with no video: use the 'visibility' property with a value of hidden
hide both video and audio: use the 'display' property with a value of none

12.1.6 Controlling media playback through script

In addition to setting fixed timeline attribute values or using declarative animation to control the playback of media elements such as 'audio', 'video', and 'animation', SVG allows scripted control. See the uDOM section on Multimedia control for details.

12.2 The 'audio' element

The 'audio' element specifies an audio file which is to be rendered to provide synchronized audio. The usual SMIL timing features are used to start and stop the audio at the appropriate times. An 'xlink:href' must be used to link to the audio content. No visual representation shall be produced. However, content authors can if desired create graphical representations of control panels to start, stop, pause, rewind, or adjust the volume of audio content.

The 'audio' element must reference content with an audio stream.

Schema: audio

    <define name='audio'>
      <element name='audio'>
        <ref name='audio.AT'/>
        <ref name='audio.CM'/>
      </element>
    </define>

    <define name='audio.AT' combine='interleave'>
      <ref name='svg.Core.attr'/>
      <ref name='svg.XLinkEmbed.attr'/>
      <ref name='svg.Conditional.attr'/>
      <ref name='svg.External.attr'/>
      <ref name='svg.AnimateTiming.attr'/>
      <ref name='svg.AnimateSync.attr'/>
      <ref name='svg.Media.attr'/>
      <ref name='svg.ContentTypeAnim.attr'/>
    </define>

    <define name='audio.CM'>
      <zeroOrMore>
        <choice>
          <ref name='svg.Desc.group'/>
          <ref name='svg.Animate.group'/>
          <ref name='svg.Handler.group'/>
          <ref name='svg.Discard.group'/>
        </choice>
      </zeroOrMore>
    </define>

Attribute definitions:

xlink:href = "<IRI>"

An IRI reference. An invalid IRI reference is an unsupported value. An empty string value (xlink:href="") disables playback of the element. The lacuna value is the empty string.

When the value of this attribute is animated or otherwise modified, if the media timeline can be controlled, then the media timeline is restarted only if the 'syncBehavior' attribute is set to independent. If the media timeline cannot be controlled, then the media timeline is unaffected by such modification.

Animatable: yes.

type = "<content-type>"

The audio format. Implementations may choose not to fetch audios of formats that they do not support. For optimizing download time by requiring a particular content format authors are encouraged to use 'requiredFormats', instead of 'type'.

Animatable: yes.

Runtime synchronization attributes

See definition.

SVG timing attributes

If the 'fill' attribute is specified, it has no effect. See definition.

The following example illustrates the use of the 'audio' element. When the button is pushed, the audio file is played three times.

Example: media01.svg

<svg width="100%" height="100%" version="1.2" baseProfile="tiny"
     xmlns="http://www.w3.org/2000/svg"
     xmlns:xlink="http://www.w3.org/1999/xlink">

  <desc>SVG audio example</desc>

  <audio xlink:href="ouch.ogg" audio-level="0.7" type="application/ogg"
        begin="mybutton.click" repeatCount="3"/>

  <g xml:id="mybutton">
    <rect width="150" height="50" x="20" y="20" rx="10"
      fill="#ffd" stroke="#933" stroke-width="5"/>
    <text x="95" y="55" text-anchor="middle" font-size="30"
      fill="#933">Press Me</text>
  </g>

  <rect x="0" y="0" width="190" height="90" fill="none" stroke="#777"/>

</svg>

This specification does not mandate support for any particular audio format. Content can check for a particular audio codec with the 'requiredFormats' conditional processing attribute.

12.3 The 'video' element

The 'video' element specifies a video file which is to be rendered to provide synchronized video. The usual SMIL timing features are used to start and stop the video at the appropriate times. An 'xlink:href' must be used to link to the video content. It is assumed that the video content may also include an audio stream, since this is the usual way that video content is produced, and thus the audio shall be controlled by the 'video' element's media attributes.

The 'video' element must reference content with a video stream.

The 'video' element produces a rendered result, and thus has 'width', 'height', 'x' and 'y' attributes.

The 'video' element can have two different transform behaviors, either geometric or pinned, depending on the value of the transformBehavior attribute. If the transform behavior is geometric, the 'video' element must establish a new viewport for the referenced document as described in Establishing a new viewport. In this case, the 'video' element supports the 'viewport-fill' and 'viewport-fill-opacity' properties. The bounds for the new viewport shall be defined by attributes 'x', 'y', 'width' and 'height'. The placement and scaling of the referenced video shall be controlled by the 'preserveAspectRatio' attribute on the 'video' element. In the case of pinned transform behavior, a new viewport must not be established. As such, 'viewport-fill', 'viewport-fill-opacity', 'width', 'height', or 'preserveAspectRatio' have no effect.

The value of the 'viewBox' attribute to use when evaluating the 'preserveAspectRatio' attribute shall be defined by the referenced content. For content that clearly identifies a 'viewBox' that value shall be used. For most video content the bounds of the video should be used (i.e. the 'video' element has an implicit 'viewBox' of "0 0 video-width video-height"). Where no value is readily available the 'preserveAspectRatio' attribute shall be ignored.

Schema: video

    <define name='video'>
      <element name='video'>
        <ref name='video.AT'/>
        <ref name='video.CM'/>
      </element>
    </define>

    <define name='video.AT' combine='interleave'>
      <ref name='svg.Core.attr'/>
      <ref name='svg.FocusHighlight.attr'/>
      <ref name='svg.Media.attr'/>
      <ref name='svg.XLinkEmbed.attr'/>
      <ref name='svg.Conditional.attr'/>
      <ref name='svg.External.attr'/>
      <ref name='svg.AnimateTiming.attr'/>
      <ref name='svg.AnimateSync.attr'/>
      <ref name='svg.Focus.attr'/>
      <ref name='svg.Transform.attr'/>
      <ref name='svg.XYWH.attr'/>
      <ref name='svg.PAR.attr'/>
      <ref name='svg.ContentTypeAnim.attr'/>
      <ref name='svg.InitialVisibility.attr'/>
      <optional>
        <attribute name='transformBehavior' svg:animatable='no' svg:inheritable='false'>
          <choice>
            <value>geometric</value>
            <value>pinned</value>
            <value>pinned90</value>
            <value>pinned180</value>
            <value>pinned270</value>
          </choice>
        </attribute>
      </optional>
      <optional>
        <attribute name='overlay' svg:animatable='no' svg:inheritable='false'>
          <choice>
            <value>none</value>
            <value>top</value>
          </choice>
        </attribute>
      </optional>
    </define>

    <define name='video.CM'>
      <zeroOrMore>
        <choice>
          <ref name='svg.Desc.group'/>
          <ref name='svg.Animate.group'/>
          <ref name='svg.Handler.group'/>
          <ref name='svg.Discard.group'/>
        </choice>
      </zeroOrMore>
    </define>

Attribute definitions:

x = "<coordinate>"

The x-axis coordinate of the rectangular region into which the video is placed. The lacuna value is '0'.

If the transform behavior of the video is geometric, this coordinate is one corner of the rectangular region. If it is pinned, this coordinate is the pin point of the rectangular region. See the 'transformBehavior' attribute for the interpretation of this attribute.

Animatable: yes.

y = "<coordinate>"

The y-axis coordinate of the rectangular region into which the video is placed. The lacuna value is '0'.

Animatable: yes.

width = "<length>"

The width of the rectangular region into which the video is placed. A negative value shall be treated as unsupported. The lacuna value is '0'.

If the transform behavior of the video is geometric, a value of zero shall disable rendering of the element. If it is pinned, this attribute shall have no effect on rendering.

Animatable: yes.

height = "<length>"

The height of the rectangular region into which the video is placed. A negative value shall be treated as unsupported. The lacuna value is '0'.

If the transform behavior of the video is geometric, a value of zero shall disable rendering of the element. If it is pinned, this attribute shall have no effect on rendering.

Animatable: yes.

xlink:href = "<IRI>"

An IRI reference to the video content. An invalid IRI reference is an unsupported value. An empty string value (xlink:href="") disables rendering of the element. The lacuna value is the empty string.

Animatable: yes.

preserveAspectRatio = [defer] <align> [<meet>]

Indicates whether or not to force uniform scaling. (See the 'preserveAspectRatio' for the syntax of <align> and the interpretation of this attribute.)

Animatable: yes.

type = "<content-type>"

The video format. Implementations may choose not to fetch videos of formats that they do not support. For optimizing download time by requiring a particular content format authors are encouraged to use 'requiredFormats', instead of 'type'.

Animatable: yes.

transformBehavior = "geometric" | "pinned" | "pinned90" | "pinned180" | "pinned270"

See attribute definition for description.

Animatable: no.

overlay = "top" | "none"

See attribute definition for description.

Animatable: no.

initialVisibility = "whenStarted" | "always"

See attribute definition for description.

Animatable: no.

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

See attribute definition for description.

Animatable: yes.

Navigation Attributes

See definition.

Runtime synchronization attributes

See definition.

SVG timing attributes

See definition.

The following example illustrates the use of the 'video' element. The video content is partially obscured by other graphics elements. This example shows the 'video' element being rendered into an offscreen buffer and then transformed and composited in the normal way, so that it behaves like any other graphical primitive such as an image or a rectangle. In this manner, the 'video' element may be scaled, rotated, skewed, displayed at various sizes, and animated.

Example: media02.svg

<svg xmlns="http://www.w3.org/2000/svg" version="1.2" baseProfile="tiny"
     xmlns:xlink="http://www.w3.org/1999/xlink"
     width="420" height="340" viewBox="0 0 420 340">
  <desc>SVG 1.2 video example</desc>
    <g>
    <circle cx="0" cy="0" r="170" fill="#da4" fill-opacity="0.3"/>
    <video xlink:href="noonoo.avi" audio-level=".8" type="video/x-msvideo"
         width="320" height="240" x="50" y="50" repeatCount="indefinite"/>
    <circle cx="420" cy="340" r="170" fill="#927" fill-opacity="0.3"/>
    <rect x="1" y="1" width="418" height="338" fill="none"
       stroke="#777" stroke-width="1"/>
    </g>
</svg>

Show this example of the 'video' element (requires an SVG Tiny 1.2 viewer and support for a Windows AVI using Motion JPEG; this is a 3.7M video file).

This specification does not mandate support for any particular video format. Content can check for a particular video codec with the 'requiredFormats' conditional processing attribute.

The content creator should be aware that video is a feature that may not be available on all target devices. In order to create interoperable content the content creator should provide a fall-back alternative by using the 'switch' element. The following feature string is defined for checking for video support: http://www.w3.org/Graphics/SVG/feature/1.2/#Video. Video may not be completely supported on a resource limited device. SVG Tiny 1.2 introduces more granular video rendering control to provide reproducible results in all environments. This control is documented in the two following sections.

12.3.1 Restricting the transformation of the 'video' element

Transforming video is an expensive operation that should be used with caution, especially on content targeted for mobile devices. Using transformed video may also lead to non-interoperable content since not all devices will support this feature. To give the content creator control over video transformation, SVG Tiny 1.2 introduces the 'transformBehavior' attribute and a corresponding feature string: http://www.w3.org/Graphics/SVG/feature/1.2/#TransformedVideo. A viewer supporting video transformation must treat the 'video' element like any other element regarding transformations. A viewer not supporting video transformation must treat the video as a point (given by the 'x' and 'y' attributes). The 'width' and 'height' attributes shall be ignored if present and instead the width and height (in device pixels) shall be taken from the media itself. The video must be displayed with its center aligned with the origin of the local coordinate system.

A content creator can use the 'transformBehavior' attribute to explicitly choose the transform behavior on a viewer supporting transformed video. This might be of interest to increase the performance of content targeting restricted devices.

Attribute definition:

transformBehavior = "geometric" | "pinned" | "pinned90" | "pinned180" | "pinned270"

Defines whether a video is transformed/resampled (in essence treated as a geometric rectangle) or pinned/unresampled (i.e., treated as a pin point for a non-geometric blit region).

The attribute can take one of the five following values:

geometric: The media shall be treated as a geometric rectangle in the local coordinate system, defined by 'x', 'y', 'width' and 'height' attributes. The media must be resampled to fill the rectangle and is subject to transformation. This is the lacuna value.
pinned: The video is displayed without rotation.
pinned90: The video is displayed with a fixed rotation equivalent to the effect of transform="rotate(90)".
pinned180: The video is displayed with a fixed rotation equivalent to the effect of transform="rotate(180)".
pinned270: The video is displayed with a fixed rotation equivalent to the effect of transform="rotate(270)".

If one of the four values 'pinned', 'pinned90', 'pinned180' and 'pinned270' is specified, the media shall be treated as a point, defined by 'x' and 'y' attributes. This point must be transformed to the nearest actual device pixel. Video at the native resolution given by the media shall then be painted on a region whose center is the pin point and whose width and height are defined by the media. The pixels must be aligned to the device pixel grid and there shall be no resampling. The values of the 'width' and 'height' attributes in this case shall have no effect on the rendering of the video.

Animatable: no.

12.3.2 Restricting compositing of the 'video' element

For the same reasons as restricting transformations the content creator might need to restrict the compositing of video with other elements. Not all devices support compositing of the video element with other content. In that case it is necessary to render the video on top of all other svg content. SVG Tiny 1.2 therefore introduces the 'overlay' attribute and a corresponding feature string: http://www.w3.org/Graphics/SVG/feature/1.2/#ComposedVideo. A viewer supporting compositing of video must render the 'video' element according to the SVG painter's model, and thus graphical elements might be rendered on top of the video. A viewer not supporting video compositing must always render the video on top of all other SVG elements.

A content creator can use the 'overlay' attribute to explicitly choose the compositing behavior on a viewer supporting composited video. This may increase the performance of content that is targeted at restricted devices.

Attribute definition:

overlay = "top" | "none"

Defines whether a 'video' is rendered according to the SVG painter's model or if it must be positioned on top of all other SVG elements.

The attribute value can be either of the following:

top: The 'video' element must not be composited on to the background as usual. Instead a temporary video canvas must be set aside and drawn last in the whole document's compositing process.
none: The 'video' must be rendered according to the SVG painter's model. This is the lacuna value.

Animatable: no.

If multiple 'video' elements have overlay="top", the drawing order of those 'video' elements follows the typical SVG rendering order.

12.3.3 Examples

The following example illustrates the use of the http://www.w3.org/Graphics/SVG/feature/1.2/#TransformedVideo feature string. A 'switch' element is wrapped around two groups. The first group will render a scaled and rotated video sequence on a viewer supporting video transformations while the second group will render the untransformed video on viewers that don't support video transformations.

Example: media04.svg

<svg version="1.2" baseProfile="tiny" xmlns="http://www.w3.org/2000/svg"
         xmlns:xlink="http://www.w3.org/1999/xlink"
     width="100%" height="100%" viewBox="0 0 400 300">
     <desc>Example of switching on the http://www.w3.org/Graphics/SVG/feature/1.2/#TransformedVideo feature string</desc>
     <switch>

       <!-- Transformed video group -->
       <g requiredFeatures="http://www.w3.org/Graphics/SVG/feature/1.2/#TransformedVideo"
             transform="translate(-21,-34) scale(1.24) rotate(-30)">
         <rect x="6" y="166" width="184" height="140" fill="none" stroke="blue"
                  stroke-width="4" />
         <video xlink:href="ski.avi" audio-level=".8" type="video/x-msvideo"
                   x="10" y="170" width="176" height="132"/>
       </g>

       <!-- Untransformed video group -->
       <g>
         <rect  x="6" y="166" width="184" height="140" fill="none" stroke="blue"
                  stroke-width="4"/>
         <video xlink:href="ski.avi" audio-level=".8" type="video/x-msvideo"
                   x="98" y="236"/>
       </g>
     </switch>
</svg>

The above images show the rendering of Example media04 in two SVG user agents: the first one supporting transformed video (on the left) and the second one not (on the right).

The following example illustrates the use of the http://www.w3.org/Graphics/SVG/feature/1.2/#ComposedVideo feature string. A 'switch' element is wrapped around two groups. The first group must render a video with text composited on top on viewers supporting composed video while the second group must render a video with text placed above the video on viewers that do not support composed video.

Example: media05.svg

<?xml version="1.1"?>
<svg version="1.2" baseProfile="tiny" xmlns="http://www.w3.org/2000/svg"
  xmlns:xlink="http://www.w3.org/1999/xlink"
     width="100%" height="100%" viewBox="0 0 400 300">
     <desc>Example of switching on the http://www.w3.org/Graphics/SVG/feature/1.2/#ComposedVideo feature string</desc>
     <rect x="2" y="2" width="396" height="296" fill="none" stroke="black"
                  stroke-width="2" />
     <rect x="106" y="66" width="184" height="140" fill="none" stroke="blue"
                  stroke-width="4" />

     <switch>

       <!-- Composited video group -->
       <g transform="translate(100 0)" requiredFeatures="http://www.w3.org/Graphics/SVG/feature/1.2/#ComposedVideo">
         <video xlink:href="ski.avi" audio-level=".8" type="video/x-msvideo"
                   x="10" y="70" width="176" height="132"/>
         <text x="20" y="100" fill-opacity="0.5" fill="blue" font-size="20">Composited title.</text>
       </g>

       <!-- Overlayed video group -->
       <g transform="translate(100 0)" font-size="18">
         <video xlink:href="ski.avi" audio-level=".8" type="video/x-msvideo"
                   x="10" y="70" overlay="top" width="176" height="132"/>
         <text x="15" y="60" fill="blue" fill-opacity="0.5" >Non-composited title.</text>
       </g>
     </switch>
</svg>

The above images show the rendering of Example media05 in two SVG user agents: the first one supporting composed video (on the left) and the second one not (on the right).

12.4 The 'animation' element

The 'animation' elements specifies an SVG document providing synchronized animated vector graphics. Like 'video', the 'animation' element is a graphical object with size determined by its 'x', 'y', 'width' and 'height' attributes. Furthermore, the 'animation' element supports timing and synchronization attributes which allow multiple animations to run with independent timelines in the same SVG document. Just like 'video' and 'image', the 'animation' element must not point to document fragments within SVG files.

An 'animation' element establishes a new viewport for the referenced file as described in Establishing a new viewport. The bounds for the new viewport are defined by attributes 'x', 'y', 'width' and 'height'. The 'preserveAspectRatio' attribute on the rootmost 'svg' element in the referenced SVG document shall be ignored (as are its 'width' and 'height' attributes). Instead, the 'preserveAspectRatio' attribute on the referencing 'animation' element shall define how the SVG content is fitted into the viewport. The same rule applies for the 'viewport-fill' and 'viewport-fill-opacity' properties.

The value of the 'viewBox' attribute to use when evaluating the 'preserveAspectRatio' attribute is defined by the referenced document's 'viewBox' value. When no value is available the 'preserveAspectRatio' attribute must be ignored, and only the translation due to the 'x' and 'y' attributes of the viewport must be used to display the content.

The referenced SVG document represents a separate document which generates its own parse tree and document object model. Thus, there is no inheritance of properties into the referenced animation. For details, see Processing of external references to documents.

The SVG specification does not specify when an animation that is not being displayed should be loaded. A user agent is not required to load animation data for an animation that is not displayed (e.g. display="none"). However, it should be noted that this may cause a delay when an animation becomes visible for the first time. In the case where an author wants to suggest that the user agent load animation data before it is displayed, they should use the 'prefetch' element.

Schema: animation

    <define name='animation'>
      <element name='animation'>
        <ref name='animation.AT'/>
        <ref name='animation.CM'/>
      </element>
    </define>

    <define name='animation.AT' combine='interleave'>
      <ref name='svg.Core.attr'/>
      <ref name='svg.FocusHighlight.attr'/>
      <ref name='svg.Media.attr'/>
      <ref name='svg.Conditional.attr'/>
      <ref name='svg.External.attr'/>
      <ref name='svg.XLinkEmbed.attr'/>
      <ref name='svg.Focus.attr'/>
      <ref name='svg.AnimateTiming.attr'/>
      <ref name='svg.AnimateSync.attr'/>
      <ref name='svg.XYWH.attr'/>
      <ref name='svg.PAR.attr'/>
      <ref name='svg.Transform.attr'/>
      <ref name='svg.InitialVisibility.attr'/>
    </define>

    <define name='animation.CM'>
      <zeroOrMore>
        <choice>
          <ref name='svg.Desc.group'/>
          <ref name='svg.Animate.group'/>
          <ref name='svg.Discard.group'/>
          <ref name='svg.Handler.group'/>
        </choice>
      </zeroOrMore>
    </define>

Attribute definitions:

x = "<coordinate>"

The x-axis coordinate of one corner of the rectangular region into which the animation is placed. The lacuna value is '0'.

Animatable: yes.

y = "<coordinate>"

The y-axis coordinate of one corner of the rectangular region into which the animation is placed. The lacuna value is '0'.

Animatable: yes.

width = "<length>"

The width of the rectangular region into which the animation is placed. A negative value is unsupported. A value of zero must disable rendering of the element. The lacuna value is '0'.

Animatable: yes.

height = "<length>"

The height of the rectangular region into which the animation is placed. A negative value is unsupported. A value of zero must disable rendering of the element. The lacuna value is '0'.

Animatable: yes.

xlink:href = "<IRI>"

An IRI reference to the animation data. An invalid IRI reference is an unsupported value. An empty attribute value (xlink:href="") disables rendering of the element. The lacuna value is the empty string.

Animatable: yes.

preserveAspectRatio = ["defer"] <align> [<meet>]

Indicates whether or not to force uniform scaling. (See The 'preserveAspectRatio' attribute for the syntax of <align> and the interpretation of this attribute.)

Animatable: yes.

initialVisibility = "whenStarted" | "always"

See attribute definition for description.

Animatable: no.

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

See attribute definition for description.

Animatable: yes.

Navigation Attributes

See definition.

Runtime synchronization attributes

See definition.

SVG timing attributes

See definition.

The example below shows basic usage of the 'animation' element. For another example, see the use and animation example in the Linking chapter.

Example: media03.svg

<svg xmlns="http://www.w3.org/2000/svg"
     xmlns:xlink="http://www.w3.org/1999/xlink"
     version="1.2" baseProfile="tiny">
  <desc>Example of two animation elements pointing to the same content.</desc>

  <animation begin="1" dur="3" repeatCount="1.5" fill="freeze"
             x="100" y="100" width="50" height="50" 
             xlink:href="bouncingBall.svg"/>
             
  <animation begin="2" x="300" y="100" width="50" height="50" 
             xlink:href="bouncingBall.svg"/>
</svg>

12.5 The 'audio-level' property

The 'audio-level' property can be applied to the 'audio', 'video' and 'animation' elements described above, the 'use' element, plus container elements such as the 'g' element.

'audio-level'

Value:	<number> \| inherit
Initial:	1.0
Applies to:	media elements, 'use' and container elements
Inherited:	no
Percentages:	N/A
Media:	visual, audio
Animatable:	yes
Computed value:	Specified value, except inherit

The 'audio-level' property specifies a value that is used to calculate the volume of a particular element. Values below 1.0 decrease it and a value of zero silences it.

An element's volume is the product of its clamped 'audio-level' property and either the clamped computed value of its parent, or the initial value (1.0) if it has no parent. Audio level clamping occurs for any values outside the range 0.0 (silent) to 1.0 (system volume). (See Clamping values which are restricted to a particular range.)

This sentence is informative: An element's volume cannot be louder than the volume of its parent.

The output signal level is calculated using the logarithmic scale described below (where vol is the value of the element volume):

dB change in signal level = 20 * log10(vol)

User agents may limit the actual signal level to some maximum, based on user preferences and hardware limitations.

If the element has an element volume of 0, then the output signal must be inaudible. If the element has an element volume of 1, then the output signal must be at the system volume level. Neither the 'audio-level' property nor the element volume override the system volume setting.

12.6 Attributes for runtime synchronization

SVG Tiny 1.2 supports the five attributes listed below from SMIL 2.1 to control runtime synchronization of timed elements. In SVG Tiny 1.2 the 'syncBehavior', 'syncTolerance' and 'syncMaster' attributes can be specified on the 'audio', 'video' and 'animation' elements. The 'syncBehaviorDefault' and 'syncToleranceDefault' attributes can be specified on the 'svg' element.

Attribute definitions:

syncBehavior = "canSlip" | "locked" | "independent" | "default"

See the SMIL 2.1 definition of 'syncBehavior' ([SMIL21], section 10.4.1).

Animatable: no.

syncBehaviorDefault = "canSlip" | "locked" | "independent" | "inherit"

See the SMIL 2.1 definition of 'syncBehaviorDefault' ([SMIL21], section 10.4.1).

Animatable: no.

syncTolerance = "<Clock-value>" | "default"

See the SMIL 2.1 definition of 'syncTolerance' ([SMIL21], section 10.4.1).

Animatable: no.

syncToleranceDefault = "<Clock-value>" | "inherit"

See the SMIL 2.1 definition of 'syncToleranceDefault' ([SMIL21], section 10.4.1).

Animatable: no.

syncMaster = "<boolean>"

See the SMIL 2.1 definition of 'syncMaster' ([SMIL21], section 10.4.1).

Animatable: no.

Example: video content synchronized with some text

The two files below illustrate how it is possible to make sure some video content can be synchronized with some text using the synchronization attributes.

Example: sync-attr-main.svg

<?xml version="1.0"?>
<svg xmlns="http://www.w3.org/2000/svg" 
     xmlns:xlink="http://www.w3.org/1999/xlink" 
     version="1.2" baseProfile="tiny" 
     viewBox="0 0 400 100" height="100%" width="100%" syncBehaviorDefault="locked">
  
  <title>Sync* Attributes</title>
  <desc>An example which illustrates the use of sync* attributes</desc>
  
  <video x="10" y="10" xml:id="myclip" 
         xlink:href="rtsp://www.example.org/mysong.m4v" syncMaster="true"/>
  <animation x="10" y="50" xml:id="mylyrics" xlink:href="timed-lyrics.svg"/>
</svg>

Example: timed-lyrics.svg

<?xml version="1.0"?>
<svg xmlns="http://www.w3.org/2000/svg" 
     xmlns:xlink="http://www.w3.org/1999/xlink" 
     version="1.2" baseProfile="tiny" 
     viewBox="0 0 400 100" height="100%" width="100%">
     
  <title>Synchronizing lyrics with video</title>
  <desc>This document contains the textual lyrics to synchronize with some video content in the referencing document</desc>

  <g fill="blue" font-family="Arial" font-size="10" transform="translate(20, 20)">
    <text xml:id="Text0" display="none">This is some text</text>
    <set xlink:href="#Text0" attributeName="display" to="inline" begin="0" end="1"/>
    <text xml:id="Text10" display="none">simulating some lyrics</text>
    <set xlink:href="#Text10" attributeName="display" to="inline" begin="1.1" end="2"/>
    <text xml:id="Text20" display="none">displayed synchronously</text>
    <set xlink:href="#Text20" attributeName="display" to="inline" begin="2.1" end="3"/>
    <text xml:id="Text30" display="none">with some video</text>
    <set xlink:href="#Text30" attributeName="display" to="inline" begin="3.1" end="4"/>
    <text xml:id="Text40" display="none">in a different document</text>
    <set xlink:href="#Text40" attributeName="display" to="inline" begin="4.1" end="5"/>
  </g>
</svg>

Since the timed elements ('video' and 'animation') do not specify their runtime synchronization behavior using the 'syncBehavior' attribute, the behavior is deduced from the 'syncBehaviorDefault' attribute on the nearest ancestor, in this case on the 'svg' element.

This attribute has the value 'locked', which means that all the timed elements in the subtree share the same timeline. In this case, the main scene timeline, the 'video' and 'animation' timelines are then locked to each other.

Then, the master is given to the video, which means that if the video is stalled in the streaming session, the timeline of the video will be paused and, as a consequence, the timeline of the lyrics and of the main scene will be paused as well.

12.7 The 'initialVisibility' attribute

The 'initialVisibility' attribute applies to visual media elements ('video' and 'animation') and is used to control the visibility of the media object before its first active duration period has started. A visible media element that is visible before activation shall have its first frame displayed. For an 'animation' element this means the referenced file rendered at time 0. For a 'video' element it means the first frame of the video sequence.

Attribute definition:

initialVisibility = "whenStarted" | "always"

Controls the visibility of the media object before its first active duration period has started.

The attribute value can be either of the following:

whenStarted: The lacuna value. Indicates that the media object is not displayed, as though the element had display="none", until its first active duration starts.
always: The media element is visible from the initialization of the parent time container (i.e. time 0 of the parent SVG document). During this time, and until the active duration starts, the media element is initialized but remains inactive.

Animatable: no.

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

Scalable Vector Graphics (SVG) Tiny 1.2 Specification

W3C Recommendation 22 December 2008

Abstract

Status of this document

Table of Contents

Authors

Acknowledgments

Expanded Table of Contents

1 Introduction

Contents

1.1 About SVG

1.2 SVG Tiny 1.2

1.2.1 Profiling the SVG specification

1.3 Defining an SVG Tiny 1.2 document

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

1.5 Compatibility with other standards efforts

1.6 Definitions

1.7 How to reference this specification

1.8 How to use this specification

2 Concepts

Contents

2.1 Explaining the name: SVG

2.1.1 Scalable

2.1.2 Vector

2.1.3 Graphics

2.1.4 XML

2.1.5 Namespace

2.1.6 Scriptable

2.2 Important SVG concepts

2.2.1 Graphical objects

2.2.2 Re-use

2.2.3 Fonts

2.2.4 Animation

2.3 Options for using SVG in Web pages

3 Rendering Model

Contents

3.1 Introduction

3.2 The painters model

3.3 Rendering order

3.4 Types of graphics elements

3.4.1 Rendering shapes and text

3.4.2 Rendering raster images

3.4.3 Rendering video

3.5 Object opacity

3.6 Parent compositing

4 Basic Data Types

5 Document Structure

Contents

5.1 Defining an SVG document fragment: the 'svg' element

5.1.1 Overview

5.1.2 The 'svg' element

5.2 Grouping: the 'g' element

5.2.1 Overview

5.2.2 The 'g' element

5.3 The 'defs' element

5.4 The 'discard' element

5.5 The 'title' and 'desc' elements

5.5.1 Applicable 'title' and 'desc'

5.5.2 Multiple 'title' and 'desc' elements

5.5.3 User interface behavior for 'title' and 'desc'

5.6 The 'use' element

5.7 The 'image' element

5.8 Conditional processing

5.8.1 Conditional processing overview

5.8.2 The 'switch' element

5.8.3 The 'requiredFeatures' attribute

5.8.4 The 'requiredExtensions' attribute

5.8.5 The 'systemLanguage' attribute

5.8.6 The 'requiredFormats' attribute

5.8.7 The 'requiredFonts' attribute

5.9 External resources

5.9.1 The 'externalResourcesRequired' attribute

5.9.2 Progressive rendering

5.9.3 The 'prefetch' element

5.10 Common attributes

5.10.1 Attributes common to all elements

The 'id' and 'xml:id' attributes

Transforming between 'id' and 'xml:id'

5.10.2 Attributes for character-content elements

6 Styling