1 Introduction
Contents
1.1 About SVG
This specification defines the features and syntax for
Scalable Vector Graphics (SVG).
SVG is a language for describing two-dimensional graphics in XML. SVG allows
for three types of graphic objects: vector graphic shapes (e.g., paths consisting
of straight lines and curves), images and text.
Graphical objects can be grouped, styled, transformed and composited
into previously rendered objects.
The feature set includes nested transformations, clipping paths, alpha masks,
filter effects and template objects.
SVG drawings 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
supplemental scripting language with access to SVG's
Document Object Model (DOM), which provides complete access to all elements,
attributes and properties. A rich set of event handlers such
as onmouseover and onclick 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 that
higher-level information be made available somehow,
either by making the original source document
available, or making an alternative version
available in an alternative 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.
1.2 SVG MIME Type
The MIME type for SVG will be "image/svg". The W3C will register this
MIME type around the time when SVG is approved as a W3C Recommendation.
1.3 Compatibility with Other Standards Efforts
SVG 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 is an application of XML and is compatible with
the "Extensible Markup Language (XML) 1.0" Recommendation
[XML10]
- SVG is compatible with the "Namespaces in XML" Recommendation
[XML-NS]
- SVG is tracking and will conform with
"XML Linking Language (XLink)"
[XLINK].
- SVG's syntax for referencing element IDs is compatible with
the ID referencing syntax in "XML Pointer Language (XPointer)"
[XPTR].
- SVG content can be styled by either
CSS (see "Cascading Style Sheets (CSS) level 2" specification
[CSS2]) or
XSL (see "XSL Transformations (XSLT) Version 1.0"
[XSLT1]).
- SVG supports relevant properties and approaches
common to CSS and XSL, plus selected semantics and features
of CSS (see SVG's Use of Cascading Style Sheets).
- SVG can be used with
"XSL Transformations (XSLT) Version 1.0"
[XSLT1].
In particular, XSLT can style XML documents, with
SVG output being a possible result of XSLT transformations.
- External style sheets are referenced using the mechanism documented
in "Associating Style Sheets with XML documents Version 1.0"
[ESS].
- SVG includes a complete Document Object Model (DOM)
and conforms to the "Document Object Model
(DOM) level 1" Recommendation
[DOM1].
The SVG DOM has a high level of compatibility and consistency
with the HTML DOM that is defined in the DOM level 1 specification.
Additionally, the SVG DOM supports and incorporates many of the facilities
described in "Document Object Model
(DOM) level 2"
[DOM2],
including support for the CSS object model and event handling.
- SVG incorporates some features and approaches that are part of the
"Synchronized Multimedia Integration Language (SMIL) 1.0 Specification"
[SMIL1], including
the 'switch' element,
the system-required attribute and
the system-language attribute.
- SVG's animation features
(see Animation)
were developed in collaboration
with the W3C Synchronized Multimedia (SYMM) Working Group,
developers of the Synchronized Multimedia Integration
Language (SMIL) 1.0 Specification
[SMIL1]. SVG's animation
features incorporate and extend the general-purpose XML animation
capabilities described in the "SMIL Animation" specification
[SMILAnim].
- SVG has been designed to allow future versions
of SMIL to use animated or static SVG content as media components.
- SVG attempts to achieve maximum compatibility with both
the "HTML 4.0 Specification"
[HTML40] and
the most recent working drafts of
"XHTML(tm) 1.0: The Extensible HyperText Markup Language"
[XHTML10].
Many of SVG's facilities are modeled directly after
HTML, including its use of
CSS [CSS2],
its approach to event handling,
its approach to its Document Object Model [DOM1].
- SVG is compatibility with W3C work
on internationalization.
References (W3C and otherwise) include:
[UNICODE],
[UNICODE21] and
[CHARMOD].
Also, see Internationalization Support.
- SVG is compatible with W3C work on Web Accessibility
[WAI].
Also, see Accessibility Support.
In environments which support [DOM2]
for other XML grammars (e.g., XHTML [XHTML10])
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.4 Terminology
Within this specification, the key words
"MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL"
are to be interpreted as described in
RFC 2119 (see [RFC2119]).
However, for readability, these words do not appear in all uppercase letters in
this specification.
At times, this specification recommends good practice for authors and user
agents. These recommendations are not normative and conformance with this
specification does not depend on their realization. These recommendations
contain the expression "We recommend ...", "This specification recommends ...",
or some similar wording.
1.5 Definitions
- basic shape
- Standard shapes which are predefined in SVG as a convenience
for common graphical operations. Specifically:
'rect',
'circle',
'ellipse',
'line',
'polyline',
'polygon'.
- 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 discussion of the SVG canvas
in the chapter on Coordinate Systems, Transformations and Units.
- clipping path
- a combination of
'path',
'text' and
basic shapes
which serve as the outline of a (in the absense of antialiasing) 1-bit mask,
where everything on the "inside" of the outline is allowed to show through
but everything on the outside is masked out.
See Clipping paths.
- container element
- An element which can have graphics elements and other container
elements as child elements. Specifically:
'svg',
'g',
'defs'
'symbol',
'clipPath',
'mask',
'pattern',
'marker',
'a' and
'switch'.
- current SVG document fragment
- The XML document sub-tree which starts with the most immediate ancestor
'svg'
element of a given SVG element
- 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 (CTM)
defines the mapping from the user coordinate system into
the viewport coordinate system.
See
Coordinate system transformations
- 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
- One of the element types that can cause graphics to be drawn
onto the target canvas. Specifically:
'path',
'text',
'rect',
'circle',
'ellipse',
'line',
'polyline',
'polygon',
'image' and
'use'.
- graphics referencing element
- A graphics element which uses a reference to a different document
or element as the source of its graphical content. Specifically:
'use' and
'image'.
- local URI reference
- A Uniform Resource Identifier [URI]
that does not include an <absoluteURI> or
<relativeURI> and thus represents
a reference to an element/fragment within the current document.
See References and the 'defs' element.
- mask
- a
container element
which can contain
graphics elements or
other container elements which define a set of graphics that
is to be used as a semi-transparent
mask for compositing foreground objects into the current background.
See Masks.
- non-local URI reference
- A Uniform Resource Identifier [URI]
that includes an <absoluteURI> or
<relativeURI> and thus (usually) represents
a reference to a different document or an element/fragment
within a different document.
See References and the 'defs' element.
- paint
- A paint represents a way of putting color values onto the canvas. A paint might consists
of both color values and associated alpha values
which control the blending of colors against already existing color values on the canvas.
SVG supports three types of built-in paint: color,
gradients and patterns.
- shape
- A graphics element that is defined by some combination of straight lines
and curves. Specifically:
'path',
'rect',
'circle',
'ellipse',
'line',
'polyline',
'polygon',
- stroke
- The operation of painting
the outline of a shape or
the outline of character glyphs in a text string.
- SVG canvas
- the canvas onto which the SVG content is rendered.
See the discussion of the SVG canvas
in the chapter on Coordinate Systems, Transformations and Units.
- SVG document fragment
- The XML document sub-tree which starts with an
'svg'
element. An SVG document fragment can consist of a stand-alone SVG document,
or a fragment of a parent XML document enclosed by an
'svg'
element. When an
'svg'
element is an descendant of another
'svg'
element, there are two SVG document fragments, one for each
'svg'
element. (One SVG document fragment is contained within another SVG document fragment.)
- SVG viewport
- the viewport
within the SVG canvas which
defines the rectangular region into which SVG content is rendered.
See the discussion of the SVG viewport
in the chapter on Coordinate Systems, Transformations and Units.
- transformation
- 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
- 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.
See current transformation matrix (CTM)
and
Coordinate system transformations
- URI Reference
- A Uniform Resource Identifier [URI]
which serves as a reference to a file or to an element/fragment within a file.
See References and the 'defs' element.
- 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
- 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 rectangular region within the current canvas
onto which graphics elements are to be rendered.
See the discussion of the SVG viewport
in the chapter on Coordinate Systems, Transformations and Units.
- 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
- 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.
1.6 Error processing
There are various scenarios where an SVG document fragment is technically in error:
- When an element or attribute is encountered in the document which is not part
of the SVG DTD and which is not properly identified as being part
of another namespace (see "Namespaces in XML" [XML-NS])
- When an element has an attribute or property value which is not permissible according to this specification
- Other situations that are described as being in error in this specification
A document can go in and out of error over time. For example, document changes
from the SVG DOM or from animation
can cause a document to become
in error and a further change can cause the document to become correct again.
The following error processing
shall.
occur when a document is in error:
- The document
shall.
be rendered up to, but not including, the first element which
has an error. (Exception: if a
'path' element
is the first element which has an error and the only errors are in
the path data specification,
then render the
'path' up to the point of the path data error.
See 'path' element implementation notes.)
This approach will provide a visual
clue to the user/developer about where the error might be in the document.
- If the document has animations, the animations
shall
stop at the point at which
an error is encountered and the visual presentation of the document
shall.
reflect
the animated status of the document at the point the error was encountered.
- A highly perceptive indication of error
shall.
occur. For visual rendering situations,
an example of an indication of error would be to render a translucent colored pattern
such as a checkerboard on top of the area where the SVG content is rendered.
- If the user agent has access to an error reporting capability such as status bar,
it is recommended that the user agent provide whatever additional detail it can to
enable the developer/user to quickly find the source of the error. For example,
the user agent might provide an error message along with a line
number and character number at which the error was encountered.
Because of situations where a block of scripting changes might cause a given
SVG document fragment to go into and out of error, error processing
shall.
occur only
at times when document presentation (e.g., rendering to the display device)
is updated. In particular, error processing
shall.
be disabled whenever
redraw has been suspended via DOM calls to suspendRedraw().