Abstract
This document lists the design principles and requirements
for future versions of the SVG language, in particular versions
1.1, 1.2 and 2.0, to be developed by the W3C SVG working group.
Refer to SVG 1.0 [SVG 1.0] for details
on the current W3C Recommendation.
Status of this
Document
This is a W3C Working Draft for review by W3C Members and
other interested parties. It is a draft document and may be
updated, replaced or made obsolete by other documents at any
time. It is inappropriate to use W3C Working Drafts as
reference material or to cite them as other than "work in
progress". This is work in progress and does not imply
endorsement by the W3C
membership.
This document was developed by the Scalable Vector
Graphics (SVG) working group as part of the W3C Graphics
Activity. The authors of this document are the SVG Working
Group members.
A list of current W3C Recommendations and other technical
documents, including Working Drafts and Notes, can be found at
http://www.w3.org/TR/.
Feedback on this document should be sent to the email list
[email protected]. This is a
public list that is
archived and also serves as the public discussion forum for
issues related to vector graphics on the Web. To subscribe send
an email to [email protected]
with the word
subscribe
in the subject line. Note that only
subscribers can post to the list.
This section represents the status of this document at
the time this version was published. It will become outdated if
and when a new version is published. The latest status is
maintained at the W3C.
Table of Contents
1. Introduction
The SVG 1.0 specification [SVG 1.0]
is a Recommendation of the W3C. SVG is a language for defining
2D graphics that uses XML syntax to describe graphical elements
that may be rendered in a resolution independent manner. The
specification defines the visual representation of the
elements, which can be used in a stand-alone SVG file or
included in another XML document within the SVG namespace.
The SVG 1.0 specification is widely implemented by viewing
and authoring tools on desktop machines. Many server-side
generation tools dynamically produce SVG content. There is an
SVG 1.0 Test Suite [SVG Test Suite],
which examines every area of the SVG 1.0 Specification and
promotes the consistent rendering of SVG content across
implementations and platforms.
The next step in the SVG process is developing the
specifications for future versions of the SVG language, as well
as profiles of SVG that target particular application areas.
This document addresses the requirements of three
specifications, SVG 1.1, SVG 1.2 and SVG 2.0. SVG 1.1 is a
modularized version of SVG 1.0, including errata from SVG 1.0
and the minumum number of new features needed to develop an SVG
profile for mobile devices [SVG
Mobile Requirements] [SVG Mobile
Profiles]. SVG 1.2 is a "dot-release" increment to the SVG
1.1 language, adding the most needed and most requested new
features to SVG without being a major revision. SVG 2.0 will
include the additional SVG 1.1 and SVG 1.2 features, and other
new features of value to the SVG community. Parallel to the
development of these versions of SVG, the SVG Working Group
will develop a number of profiles for SVG (e.g. full SVG, SVG
Tiny and SVG Basic for mobile or resource-limited devices and
an SVG Printing profile). This document describes the
requirements for the 1.1, 1.2 and 2.0 versions of the SVG
Specification, with labels suggesting which version of the
specification may meet the requirement.
Drafts of SVG 1.1 are already available [SVG 1.1]. A first draft of the future
SVG 1.2 specification is expected within a month of this
requirements document being posted for public review. A first
draft of SVG 2.0 is expected before the end of 2002. All three
specifications will be developed taking into account:
- the design goals, detailed requirements and candidate
features described in this document
- feedback on this document from the public, invited
experts and SVG Working Group members (see the Status section
for feedback instructions).
2. Design
Principles
The following design principles will be considered for SVG
1.1/1.2/2.0. These principles complement the list in the SVG
1.0 requirements document [SVG 1.0
Requirements].
2.1. General
- SVG 1.1/1.2/2.0 should be targeted as a standard feature
on desktops (web browsers, graphical applications, authoring
tools, file interchange), mobile and small devices (browsers,
user interfaces, automotive systems), printers and industrial
applications.
- SVG should be able to describe the common and extended
feature set of today's graphical authoring environments, both
tools and programs. SVG should be a common export format in
these applications.
- It must be possible to define a profile (subset of SVG)
that can be implemented on devices with resource constraints.
For example, a mobile device may not have the display
resolution or processing power for all SVG elements, and it
should be possible to create content that can be viewed on
such a device.
- New features in the specification should be accompanied
by a comprehensive test suite exercising the feature. An
essential requirement in the W3C process is the demonstration
that all features in a specification can be implemented.
Therefore, implementation feedback will play a large part in
the specification's design.
2.2. Compatible, Consistent and Extensible
- SVG 1.1/1.2/2.0 must be as compatible as possible with
the SVG 1.0 specification.
- All elements and attributes should be consistent within
SVG, and with external specifications such as CSS and XSL.
This includes the naming of elements, the set of available
attributes and the style properties that can be used on
elements.
- The SVG 1.1/1.2/2.0 specifications must be modular to
allow profiling.
2.3. Relationship to other Web formats
- New features are expressed in XML or related technologies
(e.g. style properties are compatible with CSS).
-
Compatible with and/or leverages other relevant standards
efforts, including XML namespaces, XForms, DOM3, CSS3 and
metadata. For example:
- SVG elements and attributes should be accessible via
the DOM, and if useful, the SVG DOM.
- SVG elements should raise appropriate XML Events as
needed
- SVG should be compatible with XForms User Interface
presentation
- SVG should review developments from other working
groups and examine how those features could be
integrated.
- SVG should support metadata that can be used in a
semantic web context
- Should be possible to easily embed other XML content
within SVG, and to embed SVG into other XML content. This may
require special attention in terms of event propagation and
styling properties that will require liaison with other W3C
groups.
2.4.
Graphics Features
- Complete, general-purpose Web graphics format that meets
the graphics needs of all creators and consumers of Web
content.
- Sufficiently powerful and precise to meet the needs of
professional Web designers such that they will utilize SVG
instead of raster formats in those cases where vector
graphics is a more natural or appropriate format.
- Sufficiently powerful to meet the needs of business
presentation and diagramming applications such that these
drawings will be published on the Web using SVG instead of
raster formats.
- Sufficiently compatible with the graphics design and
publishing industries' feature sets and file formats such
that there is (as lossless as possible) a straightforward
mapping from these applications and file formats into SVG.
The goals are to facilitate conversion of existing artwork
into SVG, promote the creation of lots of compelling new SVG
artwork, make it as easy as possible for the graphics design
and publishing industries to adapt existing authoring tools,
and provide for new SVG authoring tools.
- Feature set is complete enough to provide a reasonable
conversion from existing graphics formats (vector and
raster).
- To allow or include relevant enhancements from target
domains such as GIS/Mapping, CAD/Design, Mobile, Printing and
Web Design. Enhancements that are useful in the general case
may be added to SVG, while domain-specific enhancements may
require the examination of SVG interoperability with another
XML grammar.
- Should investigate unification of existing style elements
so there is a common model for existing and future rendering
elements.
- Should be compatible with the current standard imaging
model for graphics.
- Should be able to function as an application's user
interface.
2.5.
Accessible and International
- SVG content should be able to conform to the W3C Web
Accessibility Initiative Content Guidelines.
- SVG user agents should be able to conform to the W3C Web
Accessibility Initiative User Agent Guidelines. In
conjunction with the UA Working Group, the SVG Working Group
will specify how the User Agent Accessibility Guidelines
apply to SVG 1.1/1.2/2.0.
- All features in SVG should be available to the
international community.
3.
Terminology
The key words "must", "should" and "may"
are to be interpreted in the detailed requirements as
follows:
- must
- The item is an absolute requirement of the
specification.
- should
- There may exist valid reasons in particular circumstances
to ignore the item, but the full implications must be
understood and carefully weighed before choosing a different
course.
- may
- The item will be considered, but further examination is
needed to determine if the item should be treated as a
requirement.
Note that only the highlighted versions of the terms are to
be interpreted as above. Terms that are not highlighted should
be interpreted as usual.
4.
Detailed Requirements
The following is the detailed list of required features in
SVG 1.1/1.2/2.0. It is recognized that some of these
requirements may conflict or may not be possible.
4.1. General
Requirements
-
Compatibility
- SVG should be backwards
compatible. That is, no modification to SVG should cause
SVG content conforming to a particular version to be
rendered differently in viewers that conform to any
higher version of the SVG specification. [SVG 1.1] [SVG 1.2] [SVG 2.0]
- SVG 1.1/1.2/2.0 should use
the same syntax as SVG 1.0 (i.e. any new elements should be consistent with SVG 1.0).
[SVG 1.1] [SVG 1.2] [SVG 2.0]
- New attributes (or attribute values) on SVG 1.0
elements should produce the
same default behavior as SVG 1.0 wherever possible. [SVG 1.1] [SVG 1.2] [SVG 2.0]
- The rendering model of SVG 1.1/1.2/2.0 may not be identical to SVG 1.0.
However, the SVG 1.0 rendering model
should be the default.
[SVG 1.1] [SVG
1.2] [SVG
2.0]
- Ideally, updates and major revisions to the SVG 1.0
language should be accompanied
by XSLT transformation scripts to assist in updating
legacy content. [SVG 1.1]
[SVG 1.2] [SVG 2.0]
-
Modularization and Profiling
- The SVG 1.0 language must
be modularized into an SVG 1.1 specification. [SVG 1.1]
- Profiles for SVG must
describe the SVG modules that they implement, as well as
any additional information relative to the profile. [SVG 1.1]
- There must be one or more
profiles for mobile devices with resource constraints.
[SVG 1.1]
- There may be profiles for
other resource-limited devices.
[SVG 1.2]
- There should be profiles
for printers. [SVG
1.2]
- There may be a combined
SVG SMIL profile, describing how SVG 1.1/1.2 content can
be integrated with SMIL 2.0 modules. [SVG 1.1] [SVG 1.2]
-
Conformance
- Conformance criteria for the SVG specifications and
profiles must be produced. The
criteria should be separated
into sections relevant to particular application types
(e.g. SVG generators, SVG files, SVG Mobile Viewers, etc)
[SVG 1.1] [SVG 1.2] [SVG 2.0]
- Software or documents must
pass the relevant criteria to be able to claim
conformance to the particular application type. [SVG 1.1] [SVG 1.2] [SVG 2.0]
- A test suite must be
developed for each specification and profile. The test
suite must be made publicly
available. Test suites for other uses of SVG (e.g.
Accessibility Requirements) may
be developed. [SVG 1.1]
[SVG 1.2] [SVG 2.0]
- The specification should
contain a section on authoring guidelines, which may
include or refer to descriptions of methods for
generating accessible content, guidelines for authoring
tools and tips for content generation (server-side,
hand-coding, etc). [SVG
1.1] [SVG 1.2]
[SVG 2.0]
4.2 Graphical
Features
-
Shapes and Paths
- SVG may extend the current
set of predefined basic shapes, or add attributes to
existing basic shapes to increase functionality. The
predefined shapes are included to assist in the manual
generation of SVG content, as well as to provide an
efficient means in which to store common shapes. The set
of new basic shape elements may
include an arc (open, closed, pie slice), a spiral, star
and regular polygons. The set of new attributes on
existing shapes may include a
rotation angle on the ellipse element. [SVG 2.0]
- The range of path segment types
should be examined. New segment types may be added. As in SVG 1.0, the path
syntax should be efficient in
both size and processing. [SVG
2.0]
- The set of new segments may
include general splines, mathematical functions, or a
reference to another path element (allowing shared
borders on elements). Path segments
may also allow defined points (providing common
vertices for path elements). Path data may be extended to
support constraint features [SVG
2.0]
- The syntax for path data
may be enhanced to provide aliases for segment
identifiers that are potentially confusing. For example
the relative "lineto" segment is defined using a
lowercase "L" which can be mistaken for the number "1".
The alias "r" (lowercase "R")
may be allowed for relative lineto. [SVG 1.2] [SVG 2.0]
- SVG may define points and
allow shape elements and paths to reference them. This
would facilitate connection points on elements. [SVG 2.0]
- SVG may define a set of
predefined user interface controls, such as those needed
for form interaction (e.g. buttons, text fields, sliders,
etc). Many images on the web today are raster versions of
"web buttons" which could be more efficiently expressed
in SVG. This requirement will involve liason with the
XForms Working Group [SVG
1.2] [SVG
2.0]
-
Text
- SVG 1.2 should allow word
wrapping and forced line breaks for text within multiple
rectangles [SVG 1.2]
- SVG 2.0 should allow word
wrapping, forced line breaks and text flow within
multiple shapes [SVG
2.0]
- SVG text should allow
justification locations, such as the nine standard
positions (bottom, center, top with left, middle, right).
Note that this requirement will involve coordination with
the CSS and XSL groups, and investigation by the
Internationalization group. [SVG
1.2] [SVG
2.0]
- SVG may allow text to be
justified flush within a shape.
[SVG 2.0]
- The transform attribute
should be added to the tspan element [SVG 1.2]
- SVG should provide a method
to define how whitespace is handled. SVG may provide an attribute that defines
how a text element should handle whitespace, overriding
the use of the xml:space attribute. [SVG 2.0]
-
Images
- SVG should examine the
JPEG2000 specification for relevant features. [SVG 2.0]
- SVG may require support for
JPEG2000 images. [SVG
2.0]
-
Color
- SVG should define a color
element that can be referenced as a paint server in the
same manner that is currently used for gradients and
patterns. The color element
should be able to specify the opacity of the
color. [SVG 1.2]
- Furthermore, SVG should
require all potential new paint servers to be defined in
a separate element that can be referenced by the style
properties. [SVG 1.1]
[SVG 2.0]
- SVG should extend the list
of color representation spaces that are accessible within
a document. Potential color spaces are CMYK and PANTONE.
[SVG 1.2] [SVG 2.0]
- SVG may allow a palette of
colors or other paint styles to be defined, with the
style properties that can reference paint servers able to
use this palette as an indexed color table. SVG may also allow a set of alternative
palettes to be described, with the most suitable palette
for the output device chosen at rendering time. [SVG 1.1] [SVG 1.2]
-
Compositing
- SVG should allow for a
broader range of compositing operations in the rendering
model. Potential compositing operations are the modes
from the SVG 1.0 feComposite (in, over, out, atop, xor
and arithmetic) and feBlend (multiply, screen, darken,
lighten) elements, as well as the collection of blending
modes available in PDF 1.4 (overlay, soft light, hard
light, color dodge, color burn, difference, exclusion).
SVG should attempt to preserve
a default painter's rendering model. [SVG 1.2] [SVG 2.0]
-
Coordinates and
Transformations
- SVG should allow elements
to be defined in the coordinate system used by the view
port. SVG 1.0 only allows elements to be defined in the
user coordinate system, ensuring they are always affected
by the current user space to view port transformation.
Many applications, such as user interfaces, require
objects that are not affected by the user space
transformation, i.e. their position and size remain
constant. Examples of such applications are the legend on
a chart, symbols on a map and buttons in a user
interface. [SVG 1.2]
[SVG 2.0]
- SVG may allow
transformations to allow higher level matrices and
perspective transformations. The validity and extent of
this feature will require implementation feedback. [SVG 2.0]
- SVG should allow the
document to use a Y-up coordinate system. Elements that
define text rendering should
continue to use a Y-up coordinate system. [SVG 2.0]
- SVG should provide a
mechanism to name the coordinate system used by sections
of the document. For example, the coordinates used by the
elements in the SVG file may be defined in the "D/WGS84"
coordinate system. [SVG
1.1] [SVG 1.2]
[SVG 2.0]
-
Paint Servers
- SVG may include more types
of gradient elements. Potential gradient elements include
conical, rectangular, Gouraud shading, triangle mesh,
Coons patch and shaped fill (with gradient offsets
determined by the distance from the edge of the shape).
[SVG 2.0]
- SVG may support the
winding-counting fill rule (where overlaps are repeatedly
filled). [SVG 2.0]
- SVG should support the CSS
background properties on some elements, particularly the
outermost SVG element and text elements. [SVG 2.0]
- SVG may allow the user to
control the boundary of the fill. For example, the fill
could entirely overlap the stroke or remain completely
within the stroke. [SVG
2.0]
-
Stroke Styles
- SVG should support
definable stroke styles. Possible examples of defined
styles are wave strokes, strokes with multiple lines and
the brushes that are supported by many illustration
packages. [SVG 2.0]
- SVG may support more join
styles (e.g. chamfer). [SVG
2.0]
- SVG may allow the order of
stroking in the rendering process to be controlled (i.e.
to come before the fill). [SVG
2.0]
- SVG may allow the user to
control the location of the stroke. For example, the
stroke could be centered on the outline, adjacent to the
outline and outside the shape or adjacent to the outline
and inside the shape. [SVG
2.0]
-
Styling
- SVG must take into account
updates to the CSS and XSL specifications. [SVG 1.1] [SVG 1.2] [SVG 2.0]
-
Parameterized
elements
- SVG should have a mechanism
to allow parameter substitution on attributes in repeated
instances of elements, such as symbols. For example, a
grid-like structure could be constructed by repeating a
line element with different transformations. [SVG 2.0]
-
Constraints
- SVG 1.2 may have a general
constraint feature that provides flexible layout of
elements based on relations to other elements or
attributes. Constraints may affect the size and position
of elements. SVG may use XPath
and/or XSLT syntax to declaratively describe the
constraints. [SVG
1.2]
- SVG 2.0 should have a
general constraint feature that provides flexible layout
of elements based on relations to other elements or
attributes. [SVG
2.0]
-
Units
- SVG may allow CSS units in
the polylines, polygons, paths and transforms. However,
the CSS unit facility may be
deprecated in favour of an alternative approach using
constraints. [SVG
2.0]
-
Grouping
- SVG may provide a mechanism
to control rendering order, such as a "z-index"
attribute. [SVG 2.0]
- SVG may provide the concept
of layers. [SVG 2.0]
-
Vector Effects
- SVG may provide a mechanism
to apply vector effects to elements in a manner similar
to the existing raster filter effects. [SVG 2.0]
4.3.
Interactivity
-
Selection
- SVG may allow the selection
of multiple elements. [SVG
2.0]
- SVG 1.2 may allow both text
and graphical elements to be selected. [SVG 1.2]
- SVG 2.0 should allow both
text and graphical elements to be selected. [SVG 2.0]
-
Referencing
- SVG may provide a mechanism
for pointing to a particular state of the document. Where
the view element describes a region to display, the
state-based view would describe a geometric region at a
particular time in the document timeline, or after
particular events have been triggered on defined
elements. [SVG 2.0]
-
Forms
- SVG should coordinate with
the XForms Working Group. [SVG
2.0]
-
Animation
- SVG should investigate
alternative approaches to associating animation elements
with the elements being animated. [SVG 2.0]
- SVG may provide greater
control over the color space used in an animation that
modifies color (e.g. animateColor in HSV). [SVG 2.0]
- SVG 1.2 should provide a
mechanism to support streaming animations. A potential
solution is to start the document timeline when the
document loading begins (at the earliest possible point).
[SVG 1.2]
- SVG 2.0 must provide a
mechanism to support streaming animations. [SVG 2.0]
- SVG may allow the speed of
the document timeline to be controlled, in effect
speeding up or slowing down the document clock. [SVG 2.0]
- SVG should allow different
timelines in the same document. SVG
may use the syncBehavior attribute from SMIL.
[SVG 2.0]
-
Events
- SVG 1.2 may require DOM
Level 3 Events. [SVG
1.2]
- SVG 1.2 may incorporate the
XML event model [XML
Events], allowing the definition of any DOM event
listener in markup. [SVG
1.2]
- SVG 2.0 should incorporate
the XML event model [XML
Events]. [SVG
2.0]
- SVG should provide a
mechanism to trigger dynamic content based on the level
of zoom or location of the viewport. SVG may also provide a mechanism to
support a document with elements tagged with level of
detail information (e.g. maps).
[SVG 2.0]
-
Scripting
- SVG should provide a subset
of scripting facilities in XML markup. SVG may introduce an element that handles
events and modifies the DOM.
[SVG 2.0]
4.4.
Miscellaneous
-
General
Extensibility
- SVG may provide a mechanism
to allow extensions to the language, in particular
filters and paint servers. [SVG
2.0]
-
Code protection
- SVG may investigate
mechanisms for hiding SVG code from the user, with
conforming SVG viewers not allowing the user access to
the SVG document or DOM. Collaboration with the XML
Encryption and XML Signature working groups will be
necessary. [SVG 2.0]
-
Alternative content
- SVG should allow more
attributes in the tests for the switch element. For
example, content could switch on device characteristics
as well as provide alternative content based on the
version/profile of the specification to which the viewer
conforms. [SVG 1.1] [SVG 1.2] [SVG 2.0]
- SVG may provide a mechanism
to control the result of a switch element, allowing
access to alternative content that otherwise would not
have been available. [SVG
2.0]
-
Enhanced
Printing
- SVG may provide a page
description model, allowing page breaks to be defined in
SVG content. [SVG 1.2]
[SVG 2.0]
- SVG may provide DOM events
related to printing, such as an onPrint event. [SVG 1.2] [SVG 2.0]
-
Error Processing
- SVG must provide
comprehensive instructions to user agents when processing
non compliant SVG content, or content that is not from an
SVG version or profile that the user agent can handle.
[SVG 1.1] [SVG 1.2] [SVG 2.0]
References
- [SVG
1.0]
- Scalable Vector Graphics (SVG) 1.0
Specification, Jon Ferraiolo, editor, W3C, 4 September
2001 (Recommendation). See
http://www.w3.org/TR/2001/REC-SVG-20010904/ or the Latest Version
- [SVG
1.1]
- Scalable Vector Graphics (SVG) 1.1
Specification, Dean Jackson, editor, W3C, 15 February
2002 (Last Call Working Draft). See
http://www.w3.org/TR/2002/WD-SVG11-20020215/ or the Latest Version
-
[SVG 1.0 Requirements]
- SVG 1.0 Requirements Document, Jon Ferraiolo,
editor, W3C, 29 October 1998 (Working Draft). See
http://www.w3.org/TR/WD-SVGReq
-
[SVG Mobile Profiles]
- Mobile SVG Profiles: SVG Tiny and SVG Basic,
Tolga Capin, editor, W3C, 15 February 2002 (Last Call Working
Draft). See
http://www.w3.org/TR/2002/WD-SVGMobile-20020215/ or the
Latest
Version
- [SVG Mobile Requirements]
- SVG Mobile Requirements Document, Rick Graham,
Tolga Capin, editors, W3C, 3 August 2001 (Working Draft). See
http://www.w3.org/TR/SVGMobileReqs for latest
version.
-
[SVG Test Suite]
- SVG 1.0 Test Suite, See
http://www.w3.org/Graphics/SVG/Test/
- [W3C Process]
- W3C Process Document, See
http://www.w3.org/Consortium/Process/ for the latest
version.
-
[XML Events]
- XML Events, See
http://www.w3.org/TR/2001/WD-xml-events-20011026/ or the
Latest
Version