W3C

SVG 1.1/2.0 Requirements

W3C Working Draft 3 August 2001

This version:
http://www.w3.org/TR/2001/WD-SVG2Reqs-20010803.html
Latest version:
http://www.w3.org/TR/SVG2Reqs
Editor:
Dean Jackson (W3C/CSIRO) <dean@w3.org>

Copyright ©2001 W3C® (MIT, INRIA, Keio), All Rights Reserved. W3C liability, trademark, document use and software licensing rules apply.

Abstract

This document lists the design principles and requirements for future versions of the SVG language, in particular versions 1.1 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 specification.

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 www-svg2-comments@w3.org. This is a public list that is archived. Public discussion of issues related to vector graphics on the Web and SVG in particular takes place on the public mailing list of the SVG Working Group (list archives). To subscribe send an email to www-svg-request@w3.org with the word subscribe in the subject line.

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 currently a Proposed 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 will be the development of two specifications, SVG 1.1 and SVG 2.0. SVG 1.1 will include a modularized version of SVG 1.0, and new features driven by the requirements of an SVG profile for mobile devices [SVG Mobile Requirements]. Parallel to the development of SVG 1.1, the SVG Working Group will develop a number of profiles for SVG (e.g. full SVG, SVG Tiny, SVG Basic and possibly a printing profile). SVG 2.0 will include the additional SVG 1.1 features, and other new features of value to the SVG community. This document describes the requirements for the 1.1 and 2.0 versions of the SVG Specification, with labels suggesting which version of the specification may meet the requirement.

A first draft of the future SVG specification is expected approximately two months after this requirements document is posted for public review. The specification will be developed taking into account:

2. Design Principles

The following design principles will be considered for SVG 2.0. These principles complement the list in the SVG 1.0 requirements document [SVG 1.0 Requirements].

2.1. General

  1. SVG 1.1/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.
  2. 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 common export format in these applications.
  3. 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.
  4. New features in the specification should be accompanied by a comprehensive test suite examining 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

  1. SVG 1.1/2.0 must be as compatible as possible with the SVG 1.0 specification.
  2. 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.
  3. The SVG 1.1/2.0 specifications must be modular to allow profiling.

2.3. Relationship to other Web formats

  1. New features are expressed in XML or related technologies (e.g. style properties are compatible with CSS).
  2. Compatible with and/or leverages other relevant standards efforts, including XML namespaces, XForms, DOM3, CSS3 and metadata. For example:
  3. 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

  1. Complete, general-purpose Web graphics format that meets the graphics needs of all creators and consumers of Web content.
  2. 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.
  3. 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.
  4. 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.
  5. Feature set is complete enough to provide a reasonable conversion from existing graphics formats (vector and raster).
  6. 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.
  7. Should investigate unification existing style elements so there is a common model for existing and future rendering elements.
  8. Should be compatible with the current standard imaging model for graphics.
  9. Should be able to function as an application's user interface.

2.5. Accessible and International

  1. SVG content should be able to conform to the W3C Web Accessibility Initiative Content Guidelines.
  2. 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/2.0.
  3. 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/2.0. It is recognized that some of these requirements may conflict or may not be possible.

4.1. General Requirements

  1. Compatibility
    1. 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 2.0]
    2. SVG 1.1/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 2.0]
    3. 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 2.0]
    4. The rendering model of SVG 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 2.0]
    5. 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 2.0]
  2. Modularization and Profiling
    1. The SVG 1.0 language must be modularized into an SVG 1.1 specification. [SVG 1.1]
    2. Profiles for SVG must describe the SVG modules that they implement, as well as any additional information relative to the profile. [SVG 1.1]
    3. There must be a profile for mobile devices with resource constraints. [SVG 1.1]
    4. There may be profiles for other resource-limited devices. [SVG 1.1]
    5. There may be profiles for printers. [SVG 1.1]
    6. There may be a combined SVG+SMIL profile, describing how SVG 1.1 content can be integrated with SMIL 2.0 modules. [SVG 1.1]
  3. Conformance
    1. 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 2.0]
    2. Software or documents must pass the relevant criteria to be able to claim conformance to the particular application type. [SVG 1.1] [SVG 2.0]
    3. 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 2.0]
    4. 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 2.0]

4.2 Graphical Features

  1. Shapes and Paths
    1. 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]
    2. 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]
    3. 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]
    4. 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.1] [SVG 2.0]
    5. SVG may define points and allow shape elements and paths to reference them. This would facilitate connection points on elements. [SVG 2.0]
    6. 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.1] [SVG 2.0]
  2. Text
    1. SVG 1.1 should allow word wrapping and forced line breaks for text within a single rectangle [SVG 1.1]
    2. SVG 2.0 should allow word wrapping, forced line breaks and text flow within single or multiple shapes [SVG 2.0]
    3. 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.1] [SVG 2.0]
    4. SVG may allow text to be justified flush within a shape. [SVG 2.0]
    5. The transform attribute should be added to the tspan element [SVG 1.1]
    6. 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 1.1] [SVG 2.0]
  3. Images
    1. SVG should examine the JPEG2000 specification for relevant features. [SVG 2.0]
    2. SVG may require support for JPEG2000 images. [SVG 2.0]
  4. Color
    1. 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. 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]
    2. SVG should extend the list of color representation spaces that are accessible within a document. Potential color spaces are CYMK and PANTONE. [SVG 1.1] [SVG 2.0]
    3. 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]
  5. Compositing
    1. 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 2.0]
  6. Coordinates and Transformations
    1. 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.1] [SVG 2.0]
    2. 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]
    3. 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]
    4. 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 2.0]
  7. Paint Servers
    1. 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]
    2. SVG may support the winding-counting fill rule (where overlaps are repeatedly filled). [SVG 2.0]
    3. SVG should support the CSS background properties on some elements, particularly the outermost SVG element and text elements. [SVG 2.0]
    4. 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]
  8. Stroke Styles
    1. 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]
    2. SVG may support more join styles (e.g. chamfer). [SVG 2.0]
    3. SVG may allow the order of stroking in the rendering process to be controlled (i.e. to come before the fill). [SVG 2.0]
    4. 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]
  9. Styling
    1. SVG must take into account updates to the CSS and XSL specifications. [SVG 1.1] [SVG 2.0]
  10. Parameterized elements
    1. 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]
  11. Constraints
    1. SVG 1.1 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.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]
  12. Units
    1. 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]
  13. Grouping
    1. SVG may provide a mechanism to control rendering order, such as a "z-index" attribute. [SVG 2.0]
    2. SVG may provide the concept of layers. [SVG 2.0]
  14. Vector Effects
    1. 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

  1. Selection
    1. SVG may allow the selection of multiple elements. [SVG 2.0]
    2. SVG 1.1 may allow both text and graphical elements to be selected. [SVG 1.1]
    3. SVG 2.0 should allow both text and graphical elements to be selected. [SVG 2.0]
  2. Referencing
    1. SVG may provide a mechanism for pointing to a particular state of the document. Where the view element describes a region to display, the statefull 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]
  3. Forms
    1. SVG should coordinate with the XForms Working Group. [SVG 2.0]
  4. Animation
    1. SVG should investigate alternative approaches to associating animation elements with the elements being animated. [SVG 2.0]
    2. SVG may provide greater control over the color space used in an animation that modifies color (e.g. animateColor in HSV). [SVG 2.0]
    3. SVG 1.1 should provide a mechanism to support streaming animations. A potential solution is to provide a method to start the document timeline when the document is loaded. [SVG 1.1]
    4. SVG 2.0 must provide a mechanism to support streaming animations. [SVG 2.0]
    5. 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]
    6. SVG should allow different timelines in the same document. SVG may use the syncBehavior attribute from SMIL. [SVG 2.0]
  5. Events
    1. SVG should incorporate the XML event model [XML Events], allowing the definition of any DOM2 event listener in markup. [SVG 2.0]
    2. 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]
  6. Scripting
    1. 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

  1. General Extensibility
    1. SVG may provide a mechanism to allow extensions to the language, in particular filters and paint servers. [SVG 2.0]
  2. Code protection
    1. 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]
  3. Alternative content
    1. 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 2.0]
    2. 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]
  4. Enhanced Printing
    1. SVG may provide a page description model, allowing page breaks to be defined in SVG content. [SVG 2.0]
    2. SVG may provide DOM events related to printing, such as an onPrint event. [SVG 2.0]
  5. Error Processing
    1. 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 2.0]

References

SVG 1.0
Scalable Vector Graphics (SVG) 1.0 Specification, Jon Ferraiolo, editor, W3C, 19 July 2001 (Proposed Recommendation). See http://www.w3.org/TR/2001/PR-SVG-20010719/
SVG 1.0 Requirements
SVG 1.0 Requirements Document, Jon Ferraiolo, editor, W3C, 29 October 1998. See http://www.w3.org/TR/WD-SVGReq
SVG Mobile
SVG Mobile Requirements Document, Rick Graham, Tolga Capin, editors, W3C, 3 August 2001. See http://www.w3.org/TR/WD-SVGMobileReqs
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/
XML Events
XML Events, See http://www.w3.org/TR/2001/WD-xhtml-events-20010608/