SVG Requirements

Introduction to SVG Requirements

This document contains the extensive list of Design Goals and Detailed Requirements which were drafted before the SVG specification was written.

Interspersed within the Design Goals and Detailed Requirements are references into those sections of the specification which correspond to the given Design Goal or Detailed Requirement.

SVG Requirements Table of Contents

SVG Detailed Requirements

SVG Design Goals

The following are the Design Goals for SVG. Besides providing a set of high-level objectives for SVG, these goals act as the criteria by which proposed features are judged. Thus, the features list shown below under SVG Detailed Requirements should reflect the higher-level goals listed here.

These SVG Design Goals are not listed in any particular order. It is recognized that some of the goals might conflict or be unachievable and that tradeoffs will need to be made.

Open specification

The specification should be controlled by the members in the W3C, not by a single vendor. Thus, the specification should not subject to sudden change by a single vendor.
The specification should be vendor neutral and thus should not contain features biased towards a particular vendor.
EDITOR: None of the above goals has a direct impact on the specification.

Widely implemented and supported

SVG should be a standard feature in Web browsers
Implementations of SVG should be consistent so that the same visual results and behaviors exist in all conforming SVG user agents.
There should not be subset problems and incompatible generator/reader sets. Thus, there should be a single language specification, not a set of layered language specifications.
There should be widespread support in authoring applications and related tools
To promote widespread adoption and support, SVG should be specified to be as basic and simple as possible while still providing necessary features to satisfy the needs of graphics on the Web. While the chief goal is to aim at the middle ground, a basic and simple feature set will allow it to be used on devices with a wide range of resolutions and capabilities, from small mobile devices through office computer monitors to high resolution printers.
Straightforward generation via hand-authoring with a text editor or server-side scripts (e.g., CGI)
SVG should be as self-contained as possible. While SVG should leverage and be compatible with other W3C work, it should attempt to do so without introducing excessive dependencies on other specifications.
Ready availability to the casual implementor is desirable
EDITOR: The current draft of SVG attempts to meet these goals.
Reference source code is desirable
EDITOR: The above goal is independent of the specification.

Relationship to other Web standards efforts

Defined as an application of XML
Compatible with and/or leverages other relevant standards efforts, including XML namespaces, XML links (XLink), DOM, CSS, XSL and metadata. For example:
- the elements and attributes of an SVG drawing should be scriptable via the DOM
- text should be expressed as XML character data so that it can be found by search engines
- attributes which make sense to be part of a style should be expressed in CSS
The SVG working group will need to coordinate proactively with other working groups when it is more appropriate to meet the SVG requirements through modifications to other Recommendations.
EDITOR: The current draft of SVG attempts to meet these goals.

Graphics features

Complete, general-purpose Web vector graphics format that satisfactorily meets the graphics delivery needs for all creators and consumers of Web vector graphics
Sufficiently powerful and precise to meet the needs of professional Web graphic designers such that they will utilize SVG instead of raster formats in those cases where vector graphics is a more natural or appropriate format
EDITOR: The current draft of SVG attempts to meet these goals.
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
EDITOR: The current draft of SVG attempts to meet the final-form needs of these applications, but the higher-level (e.g., intelligent layout) needs of these applications are not addressed in the current draft specification. It is unclear at this time to what level the first version of SVG will attempt to address these needs.
Feature set is rich enough such that a reasonable conversion of most existing standard static graphics files into SVG is possible
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.
Compatible with the needs of non-technical persons who want a straightforward way to generate relatively simple graphics either by hand-editing or via server-based graphics generation (e.g., CGI scripts).
Compatible with high-quality, efficient printing at full printer resolution and with reliable color
Focused on basic foundation, presentation-level graphics facilities, with a critical eye toward higher-level (model-level) constructs which might be better suited to a higher-level standard which would sit on top of SVG
The working group is investigating whether other Web standards (e.g., CSS, XSL, MathML, Web Schematics) could use SVG as its low-level rendering specification. (This goal has significant dependencies on other W3C initiatives such as the W3C Formatting Model and might change accordingly.)
EDITOR: The current draft of SVG attempts to meet these goals.
The specification for SVG should take into account the possibility of building a future 3D graphics specification which either sits on top of SVG or which is entirely independent but with a similar syntax; however, the SVG working group should not let itself be slowed down or constrained by 3D upgrade path issues.
EDITOR: This goal hasn't been addressed yet.

Interactivity and Dynamic Behaviors

Allows for interactive and dynamic Web pages
EDITOR: The current draft of SVG attempts to meet these goals.

Interchange features

Suitable as a platform-independent graphics exchange format
Mechanisms for inclusion of application-specific (or industry specific) private data which would facilitate use of SVG as a application-specific (or industry-specific) native file format for authoring applications
Capable of use as a print metafile: sufficiently expressive such that a higher-level print metafile XML grammar could use SVG for its page imaging operators
EDITOR: The current draft of SVG attempts to meet these goals.

SVG Detailed Requirements

The following is the detailed list of required features and capabilities in SVG. Items which are already listed as a Design Goal are not repeated here. It is recognized that some of these requirements might conflict or may not be possible.

General requirements

Consistent visual results and behaviors across implementations
1. The specification needs to be complete and unambiguous
2. The goal is to have at least two independent implementations each of SVG viewers and SVG generators under development as the specification is defined to help find and remove ambiguities from the specification.
3. An extensive conformance test suite needs to be delivered in conjunction with the final specification.
EDITOR: The above goals are independent of the specification.
Elegant, uniform, complete and consistent
1. Wherever possible, all graphical attributes and operations should be available to all object types. For example, if 2x3 transformation matrices are available for shape objects, then 2x3 transformation matrices should also be available for text and image objects.
EDITOR: The current draft of SVG attempts to meet these goals.
Packaging
1. Stand-alone packaging: Compatible with the need of stand-alone graphics authoring packages. It should be possible for a graphics authoring application to save a stand-alone SVG file. ("Stand-alone packaging" means that an SVG file is saved as a separate, self-contained file, probably with a .svg extension on platforms where the extension is important.)
2. Fragment packaging: Compatible with the need of consolidated full-page Web authoring packages which would like to author/deliver full pages of XML with optional vector graphics elements interspersed as isolated components within the page. ("Fragment packaging" means that snippets of SVG would appear inside the content of a parent XML grammar. For example, a picture of an arrow expressed in SVG might appear inline within an XML file. The expected way this would be achieved would be by referencing the SVG namespace within the XML file.)
  EDITOR: In spec. See discussion of documents and fragments.
Performance
1. Reasonable display performance on commonly used end-user machines. (EDITOR: The current draft of SVG attempts to meet this goal.)
2. Highly efficient representation to minimize download times
  1. The working group should investigate abbreviation schemes (particularly for path data) to minimize file sizes
    EDITOR: The current draft of SVG attempts to meet this goal. This draft uses the following strategies in order to achieve minimal download times on uncompressed SVG files:
    - A rich feature set on the client-side such as gradient fills, pattern fills and filter effects allow complicated graphics to be specified with a minimal number of characters.
    - Path data can be expressed in an abbreviated form (see Path data)
    - The elements and attributes which are most commonly used in files have short names.
    - Because most attributes are expressed via CSS properties, it will be possible in some cases to minimize file size and download times by combining common sets of attributes into named, reused CSS styles.
  2. The working group should also collaborate with other working groups, such as the XML working group. on binary compression alternatives.
    EDITOR: Flate compression is very suitable for compressing XML grammars such as SVG and it is already part of HTTP 1.1.
3. Streamable (i.e., support progressive rendering)
4. Simple primitives (e.g., lines) should exhibit fast performance
  EDITOR: The current draft of SVG attempts to meet these goals. See Basic Shapes
Alternate representations
1. The working group should investigate the issue of alternative representations in the form of text strings or image data. Alternate representations as text or images might provide a good answer for backwards compatibility in some cases or provide for a faster display option for some drawings. Alternate text strings would be particularly valuable to visually impaired users.
EDITOR: The current draft of SVG attempts to meet these goals. See Accessibility Support, Backwards Compatibility and Extensibility
Backward compatibility
1. The working group should develop a reasonable backward compatibility strategy for when a user attempts to view an SVG drawing in a browser which doesn't yet support SVG.
EDITOR: The current draft of SVG attempts to meet these goals. See Backwards Compatibility.
Well internationalized
1. By virtue of being written in XML, SVG will already have baseline internationalisation capability (Unicode characters, language tagging). The working group will collaborate with the I18N working group to ensure that SVG is suitable for worldwide Web graphics.
EDITOR: The current draft of SVG attempts to meet these goals. See Internationalization Support.
Accessibility
1. The working group should ensure that adaptive interfaces for people with disabilities are fully supported, and that mapping SVG content to these contexts is easy and graceful.
EDITOR: The current draft of SVG attempts to meet these goals. See Accessibility Support.

Graphical facilities

Vector graphics shapes
(Note: in the remainder of this document, the terms "vector graphic shape" will be abbreviated to "shape" or "shape objects")
1. Path data
  1. Paths can be made up of any combination of the following:
    - Straight line segments
    - Cubic bezier curved segments
    - Quadratic bezier curved segments
    - Elliptical and circular arcs
    - No other curve types (Other curve types such as splines or nurbs are either technically very difficult, industry-specific and/or have not established themselves as industry standards as much as beziers.)
  2. Compound paths (i.e., paths with donut holes) should be supported. Both the non-zero winding and even-odd fill rules should be supported in both fill and clip operations to ensure compatibility with the design and publishing industries' existing file formats and authoring applications. (Also, it is much easier to implement these fill rules inside a renderer than it is in a file format converter.)
  EDITOR: In spec. See Paths.
2. A set of predefined shape types such as rectangles, rounded rectangles, circles and ellipses should be available so that simple objects can be defined without having to learn bezier mathematics. The exact list of predefined object types has not been decided yet.
  EDITOR: In spec. See Basic Shapes.
3. Any shape can be filled, stroked or used as a clipping path and/or mask. (See Fill options, Stroke options and Stenciling and masking, below.)
  EDITOR: In spec. See Painting: Filling, Stroking and Marker Symbols and and Clipping, Masking and Compositing.
Text data
1. Text strings should be expressed as XML character data which could be marked up with arbitrary XML name spaces. (Text strings as XML character data allow search engines to find the strings.)
  EDITOR: Text strings can either be expressed as XML character data or as XPointer references to other objects where the text string is expressed as XML character data. See The 'text' element
2. All text/font attributes from CSS should be supported. Complete support for CSS is what the Web community will expect. (See CSS support, below)
  EDITOR: All CSS text/font attributes that seem to make sense for final-form text are available. See Text and Font Properties
3. It is clear that precise text sizing/positioning is a requirement for the graphics design community. Thus, SVG should allow for precise control of text sizing, positioning, rotation, and skewing on a character-by-character basis. In particular, the working group should look to see if this feature could be packaged as to provide for precise text on a path.
  EDITOR: Precise text positioning is available because it is possible to position individual characters and to locate the glyph origin at a particular location. See The 'text' element. Also, SVG will include a built-in text-on-a-path feature. See Text on a path.
4. It is clear that precise control of fonts and glyphs is a requirement for the graphics design community. It should be possible to achieve precise control of the exact font and the exact glyphs within a given font to use for a given character sequence so that graphic artists have a way to ensure that the end user sees what was intended
  EDITOR: Precise control of font by name is possible using the font specification from CSS which SVG uses. (However, this still leaves open the possibility of the wrong version of the given font being used; however, there are ways to set up your font specification such that correct versioning can be achieved in all but highly unusual circumstances.) Precise control of glyphs is available in SVG. See Alternate Glyphs. SVG offers SVG fonts, which allows for exact control over glyph outlines, with the limitation that SVG fonts are unhinted.
5. The same fill/stroke/clip/mask capabilities that can be used with vector data should also be available to text data. For example, it should be possible to fill a text string with a gradient or stroke it with a dashed line pattern. This is a widely used feature in the graphics design world and is required for compatibility with existing graphics content.
  EDITOR: In spec. See Painting: Filling, Stroking and Marker Symbols.
6. The working group hasn't investigated yet whether it is advisable to provide a capability to automatically position a text string relative to another graphical element (e.g., automatically centering a text string within a rectangle). It is clear that such a feature would be a great convenience for hand-coders of certain types of drawings, such as diagrams. The working group should investigate whether there is an easy-to-use (for a hand-coder) yet robust and elegant way of achieving this.
  EDITOR: Not in spec. Some of this can can achieved via clever use of transforms and CSS alignment properties.
7. Having a text string determine the dimensions of a parent graphical object (e.g., a box is drawn to fit around a text string) is too high-level of a construct and is not planned for version 1 of SVG.
  EDITOR: Not in spec. In some cases, will be possible via JavaScript and the DOM.
8. Adding a text-on-a-path capability to SVG is still under consideration. The working group recognizes that there are many technical complexities which make it difficult to design the feature in such a way that it will be both sufficiently powerful and sufficiently compatible with the needs of various authoring scenarios.
  EDITOR: SVG will include a built-in text-on-a-path feature. See Text on a path.
Image data
1. The same image formats available to HTML should be available to SVG
  EDITOR: In spec. See Images.
2. The working group hasn't had time yet to address the issue of color management on image data. The goals will be to:
  1. achieve compatibility with how other specifications (e.g., HTML) perform color management on image data
  2. (just like the rest of SVG) take full advantage of color management systems when supported by the browser and/or the platform operating system (see Color support below)
  3. if different ICC profile are specified both as an attribute on an image and embedded within the image, the attribute should win
  EDITOR: The spec doesn't address this issue directly. The likely resolution is that SVG user agents should support profiles supplied with images.
Color support
1. All colors need to be specified in the sRGB color space for compatibility with other Web standards.
  EDITOR: In spec. See Colors.
2. It is clear that reliable color is important to both end users and Web content creators. sRGB does not answer all precise color needs, and most desktop platforms support the more complete ICC-based color management system. Thus, an alternative ICC-based color representation should be available for all color attributes. If the SVG user agent supports color management, then the ICC color takes precedence over the sRGB color.
  EDITOR: In spec. See Colors.
3. There has been little discussion so far on spot color support. Spot colors might be possible by specifying then using ICC profiles (perhaps via a Named Color profile), or by storing spot color information as private data (metadata) in the SVG file.
  EDITOR: Not in spec.
Transparency support
Transparency support is becoming commonplace in authoring applications and is widely used today in Web animations.
1. Many existing authoring applications achieve transparency by adding an opacity property wherever a color property is allowed. For compatibility with these applications, and because this represents a good technical solution to many transparency needs, wherever a color property is allowed, there will be a corresponding opacity property which indicates how transparent a given object/component/attribute should be when blended into its background
  EDITOR: In spec. See 'fill-opacity', 'stroke-opacity' and Object And Group Opacity: the 'opacity' Property.
2. In group opacity, the collection of objects that makes up a group is (in effect) drawn into a temporary area in memory, and then the temporary area is blended as a single unit into the background graphics. Group opacity is necessary when you have an aggregate object such as a automobile which is drawn as a collection of overlapping, opaque components (e.g., the hubcap might be an opaque circle that is drawn on top of an opaque tire) and you want to blend that object as a unit into the background. Group opacity is a requirement for many animation applications and has utility with static graphics also. It is straightforward to implement, particularly once you have support for transparent image objects, which is needed for GIF and PNG. It is infeasible to achieve these effects without this feature. Thus, group opacity should be supported in SVG.
  EDITOR: In spec. See Object And Group Opacity: the 'opacity' Property.
3. The working group decided that identification of a transparency/blue-screen/chromaKey color will not be supported for shapes and text because the opacity features are sufficient. However, the transparency color feature that exists in image file formats such as GIF and PNG will be supported.
  EDITOR: Not in spec because we decided not to do support chromaKey.
4. See Compositing, below.
Grouping and layering
1. There needs to be an ability to define groups (i.e., collections) of objects to allow for convenient access for scripting applications. Groups should have the following attributes (among others), all of which are accessible and/or controllable via scripting:
  1. Unique ID
  2. z-index for explicit layering
  3. visibility
  4. transformations
  5. opacity
  EDITOR: In spec. See Grouping and Naming Collections of Drawing Elements: the 'g' Element.
2. Implicit layering: unless an explicit z-index value is provided, objects will be drawn bottom-to-top in the order which they appear in the input stream. This strategy is compatible with most popular graphics file formats.
  EDITOR: In spec. See SVG Rendering Model.
3. Explicit layering: objects or collections of objects can be assigned an explicit z-index value, which takes precedence over the implicit bottom-to-top drawing order. (The bottom-to-top drawing order of objects with the same z-index relative to each other is the the order in which they appear in the input stream.) This explicit layering is a requirement for achieving certain types of animation effects.
  EDITOR: Not in spec. The working group decided that a z-index effect can be achieved either by having CSS manage multiple SVG drawings or by rearranging graphical elements via the DOM. A z-index option would complicate implementation and streaming for little gain.
Template objects/symbols
1. There should be a capability for defining template objects that can be instantiated multiple times with different attributes.
2. The template objects should be able to establish a full set of default attributes, and the instantiated objects should be able to override any of these default attriubutes.
  EDITOR: In spec. See The 'use' element.
Fill options (i.e., painting the interior of a shape or text object)
The following fill options should be available:
1. Solid-color fill (see Color support above)
  EDITOR: In spec. See Painting: Filling, Stroking and Marker Symbols.
2. Gradients
  1. Multiple gradient stops will be supported (not just two)
  2. Both linear and radial gradients will be supported
  3. It is still an open issue within the working group whether additional gradient types should be supported. Examples: conical, elliptical, square, rectangular, Gouraud shaded triangle and rectangular meshes.
  4. Gradients should allow for both a linear ramp between gradient stops and a well-defined sigma function for the calculation of the intermediate colors between the stops.
  5. For all gradients, the specification should provide details for the exact behavior of the gradient ramp. If there is a disagreement about what the gradient ramps should be, priority should be given to: (1) making sure the gradient ramp rules are consistent with real-world lighting effects, (2) retaining compatibility with as much existing content as possible (with a bias towards existing content whose users really care about how their gradients look)
  6. The suggestion has been made to allow for substitution of a different color table for use with a given gradient. (The color stop positions stay the same, but the colors used change.) This suggestion hasn't been discussed yet in the working group.
  EDITOR: In spec. See Gradients.
3. Patterns (i.e., tiled object fill)
  1. Any objects (i.e., shapes, images, text) can be used to fill any other objects
  2. When objects are used to fill other objects, parameters can be set to achieve tiling effects.
  3. The tiling options should be at least as capable as those found in the file formats used by the design and publishing industries to ensure compatibility with existing artwork and authoring applications.
  EDITOR: In spec. See Patterns.
4. Other fill styles - The working group hasn't decided yet whether other fill styles such as fractal patterns are appropriate.
  EDITOR: The working decided not to support other fill styles in SVG 1.0.
5. Custom fill styles - See Extensibility, below.
  EDITOR: Not in spec. The working group decided not to define complete rules for extending the SVG user agent. Extensibility is still possible to an individual user agent, but at this time their is no defined standard approach. See Extensibility.
Stroke options (i.e., drawing the outline of a shape or text object)
1. The same attributes available for filling an object (see Fill options, above) should be available to stroke an object. For example, you should be allowed to stroke with a pattern.
  EDITOR: In spec. See Stroke Properties.
2. The set of stroke options should be at least as capable as the stroke options in the file formats used by the design and publishing industries
  1. Arbitrary, continuous values for line width
  2. The working group hasn't reached consensus yet on whether SVG should support hairlines (i.e., instructing the device to draw the thinnest possible line)
  3. User-defined dash patterns and initial phase offset
  4. Caps, joins and miterlimits
  EDITOR: In spec. See Stroke Properties.
3. Arrowheads and polymarkers
  1. There should be a small set of predefined arrowheads
  2. Arrowheads are optional and can be placed at the start and/or end of path objects
  3. The working group should investigate the possibility of providing for custom "arrowheads" at the start and/or end of a path object which are defined by referencing a different graphical object or group. This capability would solve the following needs:
    - Diagramming applications might use arrowheads extensively, but the predefined arrowheads might not be satisfactory
    - Graphic designers who want to attach arrowheads to drawings will want complete control of the visual characteristics of their arrowheads
    - This feature can be leveraged to provide a polymarker capability for applications such as scatter diagrams
  EDITOR: In spec. See Markers.
Transformations
1. Arbitrarily nested 2x3 matrix transformations should be available. This facility is necessary to ensure compatibility with existing artwork and authoring tools.
  1. 2x3 matrices are sufficient to achieve any types of translation, scaling, rotation and skewing
  2. Transformation matrices can be nested to an arbitrary depth. A given transformation matrix is concatenated with the transformation matrices of all parent objects.
  EDITOR: In spec. See Coordinate systems and transformation matrices.
2. In the spirit of making SVG reasonably easy to use for content creators who would have difficulty constructing 2x3 matrices, SVG should offer an alternative set of simpler transformation attributes (e.g., rotation=, scale=). The SVG specification, however, needs to defined unambiguously what should happen if both the simpler transformation attributes and a 2x3 transformation matrix is provided.
  EDITOR: In spec. See Coordinate systems and transformation matrices.
3. These transformations should apply to all object types (shapes, images and text) in a uniform and consistent manner
  EDITOR: In spec. See Coordinate systems and transformation matrices.
4. Transformed objects should have the option of exhibiting true scalability (where all attributes should scale uniformly, and linewidths, images and text should scale along with the sizes of the shapes). Additionally, transformed objects should also have the option of selective scalability such that certain attributes (e.g., stroke size and textsize) are invariant.
  EDITOR: True scalability is in the current draft spec. There are some capabilities for selective scalability by setting properties such as linewidths and font sizes using Transformed CSS units. See Coordinate systems and transformation matrices.
Coordinate systems, relationship to CSS positioning
1. SVG should use CSS positioning for establishing a viewport for an outermost SVG element, such as an <svg>...</svg> complete drawing or an SVG fragment within an XML Web page.
2. SVG will support local user coordinates
3. Real number values (i.e., an integer followed by a possible decimal fractional component) should be possible for all appropriate attributes and coordinates. The language definition itself should not inhibit infinite precision.
EDITOR: In spec. See Coordinate Systems, Transformations and Units.
Antialiasing
1. It is clear that the graphics design community not only wants antialiasing to be available, but also wants to have the ability to turn antialiasing on/off on an object basis in order to achieve precise control of the rendering and possibly to control drawing speed. Thus, there will be an antialias control attribute on each graphics object in SVG.
  EDITOR: In spec. See 'shape-rendering', and 'text-rendering' and 'image-rendering'.
2. Antialiasing adds a significant burden to the casual implementor and isn't a requirement for all potential applications of SVG, such as viewing CAD drawings. Thus, antialiasing control will be regarded as a hint to the SVG user agent, which can choose whether or not to honor it. Major general-purpose implementations of SVG user agents such as commercial Web browsers should honor and implement the antialiasing control hint.
  EDITOR: In spec. See 'shape-rendering', and 'text-rendering' and 'image-rendering'.
Stenciling and masking
1. Clipping paths
  Clipping paths are a commonly used feature in existing artwork and an integral part of all authoring products used by graphic designers. Clipping paths are as fundamental to the design and publishing industries' existing file formats and authoring tools as are nested transformation matrices. Clipping is relatively easy to implement in viewers using a raster mask approach in device space if you have code for drawing a filled path into an offscreen buffer. Nested clipping paths are easy to achieve on top of an unnested clipping path implementation by just looping through each parent clipping path one after another. The performance overhead with nested clipping paths in animation scenarios is probably small relative to other necessary computations (e.g, filling and stroking) and can be overcome on the user end by simply avoiding/minimizing the use of the feature. Without nested clipping paths, converters from the design and publishing industries' existing file formats will have a significant burden in determining how to flatten the nested clipping paths they encounter. Nested clipping paths are necessary to provide lossless translation from the design and publishing industries' existing file formats.
  1. Any shape or text object can be used as a hard-edge clipping path
  2. Clipping paths can be nested arbitrarily to ensure compatibility with existing artwork and authoring tools.
  EDITOR: In spec. See Clipping Paths.
2. Masks
  8-bit masking is a fundamental feature on all operating systems, and a key feature for both static and dynamic Web pages.
  1. Any graphics object (i.e., shape, text, or image) can be used as an 8-bit alpha mask to control the alpha-compositing of a different object (or group/collection of objects) into other objects
  EDITOR: In spec. See Masking.
Client-side filter effects such as shadowing
Client-side filters provide for the possibility of significant file size and download time savings in many applications. An example is text drawn with a glow effect and a drop shadow. If client-side glow and drop shadow filters were available, then only the text string and the names of the filters would need to be downloaded, instead of today, where the text needs to be converted to a raster by the author.
1. SVG should include a set of built-in client-side filter effects for commonly used effects such as shadowing. The definitions of these effects should be unambiguous so that all implementations produce the same visual results.
  EDITOR: In spec. See Filter Effects.
2. Additionally, the working group should investigate the feasibility of a general filter mechanism which would allow for custom filter effects to be downloaded and applied to a given graphical object (see Extensibility, below)
  EDITOR: Not in spec. The working group decided not to define complete rules for extending the SVG user agent. Extensibility is still possible to an individual user agent, but at this time their is no defined standard approach. See Extensibility.
Compositing
Compositing means the rules by which a foreground object's colors are blended into a background object's colors. There are many different approaches to compositing. Alpha compositing (where each pixel has an 8-bit alpha channel which determines how opaque that pixel is) is the most common, but even this method has multiple variations.
1. The working group needs to define standard rules for how alpha compositing should work. Which color space (sRGB? Lab?)? What are the exact formulas?
  EDITOR: In spec. This document will call for alpha compositing in the sRGB color space using simple alpha and (1-alpha) algorithms. See Simple Alpha Blending/Compositing.
2. The working group needs to decide whether SVG should offer multiple compositing options as standard features. Should SVG support all of the Porter/Duff compositing options? Additionally, Photoshop offers many Adjustment Layer options. Should these be supported?
  EDITOR: In spec. Some simple Photoshop blending is available via the feBlend filter effect. Porter-Duff compositing is available via the Composite filter effect. See Filter Effects.
3. See Extensibility, below.
CSS support
1. All CSS text/font attributes from the most recently approved CSS recommendation should be honored by all conforming SVG user agents.
  EDITOR: All CSS text/font attributes that seem to make sense for final-form text are available. See Text and Font Properties
2. The issue of CSS inheritance is still open. It is unclear that the standards world will have addressed how a parent XML/HTML grammar passes its current style table to a child grammar. Until this issue is addressed, the SVG working group cannot promise that version 1 of SVG will support the inheritance of CSS styles from a parent grammar. The working group should work towards achieving this highly desirable capability, however. Representatives from the CSS and XSL have requested working with the SVG working on style sheet issues. They would like to discuss:
  1. use either XSL or CSS stylesheets within SVG
  2. use stylesheets to apply properties to both the text AND graphic objects/assemblies within an embedded SVG component (to provide/enforce "house style" or common properties across all illustrations in a document).
  EDITOR: In spec. See The Scope/Range of CSS Styles.
Connectable reference points
Connectable reference points are useful constructs for many applications. In particular, diagramming applications could use connectable reference points to define the start and end points for lines that connect two different objects. The difficulty with connectable reference points is that they might introduce a large degree of complexity into the specification and the various implementations. It might be better to leave connectable reference points to a higher-level XML grammar which sits on top of SVG.
1. It is not a requirement for version 1 of SVG to provide for a mechanism for defining connectable reference points. This is a complex issue which might be better served by a higher-level XML grammar.
2. However, the working group should not exclude this as an option for version 1 of SVG. If one of the working group members can come up with a good proposal, then the working group should consider the proposal seriously.
3. See DOM access, below, for more on connectable reference points.
EDITOR: Not in spec.
Parameter substitution and formulas on coordinates
Parameterized graphic objects, possibly built using a set of formulas to define how the object grows and stretches based on the values of its parameters and other aspects of the graphics, would provide for a powerful "intelligent graphics" capability. However, such as feature opens up many complex issues which might be better off in a higher-level XML grammar which sits on top of SVG.
1. Parameter substitution and formulas on coordinates are not requirements for version 1 of SVG.
2. A simple parameter substitution strategy, however, might be easy to define, simple to implement, and provide lots of value. In other words, a simple parameter substitution strategy might provide 90% of the value at 10% of the effort. If one of the working group members can come up with a good proposal, then the working group should consider the proposal seriously.
3. It is harder to conceive of a simple formula-based coordinate capability. However, if someone of the working group members can come up with a good proposal, then the working group should consider the proposal seriously.
EDITOR: Not in spec.
Ability to control whether a given object is printed.
1. When the working group considers this feature, it should see whether CSS's print control features are adequate.
EDITOR: CSS print control features are adequate.

Interaction

Zoom and pan
1. An SVG user agent should support zoom and pan on graphics, with true scalability. Thus, all objects and attributes (including such things as text and linewidths) should grow/shrink uniformly with the zoom level.
EDITOR: In spec. See Zoom and pan control.
Links
1. It should be possible to assign a link to any graphic object or group.
2. SVG should support all of the kinds of links into and out of a drawing as would be appropriate. For example, it should provide for links to other views in the same file or links to external media (i.e., a URL). Also, it should be possible to link into a particular view within an SVG drawing.
3. As much as is appropriate, SVG should be compatible with XLink.
  EDITOR: In spec. See Linking. SVG uses XLink for all references.
4. The working group discussed briefly the concept of linking into a moment of time within an animation application. This should be investigated by the working group as the specification is developed.
  EDITOR: Not in spec.
Event handling
1. It should be possible to assign event handlers to an individual graphic object or group.
2. The list of event handlers should at least be as extensive as what is available for HTML (e.g., mouseovers, mouseclicks).
3. Additional event handlers might prove to be valuable. For example, an onzoom event handler might prove very useful to control what content appears based on zoom level. The working group should investigate onzoom and other possible event handlers.
EDITOR: In spec (including an onzoom event handler). See Event Handling
Object selection, copying/pasting to clipboard
1. It is highly desirable but not required that SVG viewing user agents have the ability to selectively copy/paste graphical elements, particularly from the browser to the desktop environment.
2. The working group has not investigated yet whether it makes sense to specify an object selection mechanism in SVG. However, it is clear that the ability to select part of a drawing is a requirement for clipboard/exchange purposes.
3. A particular detail is selecting text for the purposes of copying to the clipboard. The working group hasn't discussed yet whether it should be possible to select text strings (complete or partial) from within an SVG user agent.
EDITOR: The spec includes a provision for selecting text for the purposes of copying to the clipboard. The spec doesn't require selecting and copying other graphic object types. See Text Selection
DOM access
1. SVG should provide for complete DOM support for all attributes and elements.
2. To provide robust hooks for animation applications, the DOM should expose graphic objects down to the individual point.
3. Supplemental utility methods (e.g., query an object's bounds, its center, its perimeter as expressed as a path, access to "connectable" points for callouts or connection lines) would be very helpful to people writing scripts that drive SVG drawings or to higher level grammars (e.g., Web Schematics or MathML) which might want to perform layout based on the bounds of a given graphics object. The SVG working group should collaborate with the DOM working group to investigate whether it is possible within the constraints of DOM to provide such utility methods.
EDITOR: SVG supports DOM level 1 and DOM level 2. We have concluded that SVG should have utility functions. SVG-specific utility functions are described in SVG DOM. Techniques for doing animation via the DOM are described in DOM animation example.
Animation
Built-in animation primitives will not be part of SVG. Animation will only be possible via the DOM or a different specification, which might sit on top of SVG.

EDITOR: Based on public feedback, we changed our mind. SVG contains animation primitives. See Animation.

Miscellaneous

Inclusion of private data (metadata)
To promote the use of SVG as an interchange format or as a component of higher-level graphics languages, there needs to be a provision for inclusion of application-specific or industry-specific private data within an SVG drawing.

EDITOR: In spec. See Private Data.
Extensibility
It is highly desirable that SVG be extensible to cope with changing requirements and for providing many valuable hooks to allow for creation of more efficient and compelling Web pages. A well-designed extensibility mechanism can allow for tomorrow's innovations to be available in today's browsers (i.e., no need to wait for a new version of the standard to be defined an implemented in browsers). A well-designed extensibility mechanism could be the best solution for many valuable features such as client-side filters on graphics data. Possible extensibility facilities are custom paint servers (for filling and stroking), custom object types, custom filters, custom compositing engines and custom color spaces. However, defining a useful and workable extensibility mechanism is very difficult and frought with many obstacles, such as deficiencies in cross-platform language standards. Thus, the working group should look into an extensibility mechanism as a highly desirable feature and review proposals from the members, but an extensibility mechanism is not an absolute requirement for version 1 of SVG.

EDITOR: Not in spec. The working group decided not to define complete rules for extending the SVG user agent. Extensibility is still possible to an individual user agent, but at this time their is no defined standard approach. See Extensibility.
Embedded components to achieve self-contained graphics files
1. Images - There has been some strong initial feedback has been that SVG should provide for embedded images. The working group should collaborate with other working groups (e.g., XML) to investigate the feasibility of allowing for embedded images within an SVG drawing.
  EDITOR: Not in spec. With the performance improvements in HTTP 1.1, images can be referenced just as in HTML without significant performance penalty.
2. Fonts - There has been some strong initial feedback has been that SVG should provide for embedded fonts. The working group has yet to make decisions on this issue. The working group should collaborate with other working groups (e.g., XML) to investigate the feasibility of allowing for embedded fonts within an SVG drawing.
  EDITOR: It is only possible to embed SVG fonts.