Scalable Vector Graphics (SVG) 1.2

W3C Working Draft 15 November 2002

This version:
Latest version:
Dean Jackson, CSIRO/W3C, <dean@w3.org>
See Author List


This Working Draft specifies version 1.2 of the Scalable Vector Graphics (SVG) Language, a modularized language for describing two-dimensional vector and mixed vector/raster graphics in XML

Status of This Document

This section describes the status of this document at the time of its publication. Other documents may supersede this document.

This document is the first public working draft of this specification. It lists the potential areas of new work in version 1.2 of SVG and is not a complete language description. In most cases, the descriptions in this document are incomplete and simply show the current thoughts of the SVG Working Group on the feature. This document should in no way be considered stable. This version does not include the implementations of SVG 1.2 in either DTD or XML Schema form. Those will be included in subsequent versions, once the contents of this language stabilizes.

This document has been produced by the W3C SVG Working Group ( members only ) as part of the W3C Graphics Activity within the Document Formats Domain.

We explicitly invite comments on this specification. Please send them to www-svg@w3.org: the public email list for issues related to vector graphics on the Web. This list is archived and acceptance of this archiving policy is requested automatically up on first post. To subscribe to this list send an email to www-svg-request@w3.org with the word subscribe in the subject line.

The latest information regarding patent disclosures related to this document is available on the Web. As of this publication, the SVG Working Group are not aware of any royalty-bearing patents they believe to be essential to SVG.

Publication of this document does not imply endorsement by the W3C membership. A list of current W3C Recommendations and other technical documents can be found at http://www.w3.org/TR/. W3C publications may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to cite a W3C Working Draft as anything other than a "work in progress."

Table of Contents

1. Text Wrapping

SVG 1.2 enables a block of text to be rendered inside a shape, while automatically wrapping the text into lines, using the flowText element. The idea is to mirror, as far as possible, the existing SVG text elements.

1.1 The flowText element

The flowText element specifies a block of text to be rendered. It contains a flowLayout element that defines regions in which the child flowDiv element of the flowText should be laid out flowed into.

The following is a extract of an XML Schema that described the flowText element.

<xs:element name="flowText">
      <xs:element ref="flowLayout"/>
      <xs:element ref="flowDiv"/>
    <xs:attributeGroup ref="PresentationAttrs"/>
    <xs:attributeGroup ref="StyleAttrs"/>

1.2 The flowLayout element

The flowLayout element contains a set of shapes in which the text content of a parent flowText element is to be laid out. The children of a flowLayout element are flowRegion elements.

The flowLayout element and its children are never rendered.

The following is a extract of an XML Schema that described the flowLayout element.

<xs:element name="flowLayout">
      <xs:element ref="flowRegion" minOccurs="0" maxOccurs="unbounded"/>

1.3 The flowRegion element

The flowRegion element can define a rectangular region in the current user coordinate system through it's x, y, width, and height attributes, or it may reference existing geometry through it's xlink:href attribute.

When used the xlink:href must directly reference path, text, or basic shape elements. Indirect references are an error.

The following is a extract of an XML Schema that described the flowtext element.

<xs:element name="flowRegion">
    <xs:attribute ref="xlink:href"/>
    <xs:attribute name="x"/>
    <xs:attribute name="y"/>
    <xs:attribute name="width"/>
    <xs:attribute name="height"/>

The margin properties behave as described in the CSS 2 specification Section 8.3. When percentage units are used they are percentages of the bounding box of the view port.

1.4 The flowDiv element

The flowDiv element specifies a block of text to be inserted into the text layout, and marks it as a division of related text. The children of the flowDiv element will be rendered as a block: offset before and after from their parent's siblings. By separating the logical order of text (in successive flowDiv elements) from the physical layout (in regions, which can be presented anywhere on the canvas) the SVG document structure encourages creation of a default, meaningful linear reading order while preserving artistic freedom for layout. This enhances accessibility.

The following is a extract of an XML Schema that described the flowtext element.

<xs:element name="flowDiv">
    <xs:choice minOccurs="0" maxOccurs="unbounded">
      <xs:element ref="flowPara"/>
      <xs:element ref="flowRegionBreak"/>
    <xs:attributeGroup ref="PresentationAttrs"/>
    <xs:attributeGroup ref="StyleAttrs"/>

The space-before, space-after properties behave as described in the XSL specification sections 7.10.5 & 6.

1.5 The flowPara element

The flowPara element marks a block of text as a logical paragraph. The children of the flowPara element will be rendered as a block: offset before and after from their parent's siblings.

The following is a extract of an XML Schema that described the flowPara element.

<xs:element name="flowPara">
  <xs:complexType mixed="true">
    <xs:choice minOccurs="0" maxOccurs="unbounded">
      <xs:element ref="flowRegionBreak"/>
      <xs:element ref="flowLine"/>
      <xs:element ref="flowTref"/>
      <xs:element ref="flowSpan"/>
    <xs:attributeGroup ref="PresentationAttrs"/>
    <xs:attributeGroup ref="StyleAttrs"/>

The 'space-before', 'space-after' properties behave as described in the XSL specification sections 7.10.5 & 6.

'text-index' behaves as described in the CSS 2 specification. SVG viewers are required to support negative values for text-indent.

'text-align' behaves as described in the CSS 2 specification Section 16.2. As per the CSS specification SVG viewers are not required to implement the value 'justify' except by mapping it to 'left' or 'right' as the CSS Specification suggests. Authors should be aware that use of 'justify' may lead to implementation specific behaviour.

'preformatted' This has the sole effect of turning off the suppression of non-printing (white space) characters at the start of a line.

Whether or not to have a 'preformatted' attribute is currently in discussion.

1.6 The flowSpan element

The flowSpan element specifies a block of text to be rendered inline, and marks the text as a related span of words. The flowSpan element is typically used to allow a subset of the text block, of which it is a child, to be rendered in a different style, or to mark it as being in a different language.

The following is a extract of an XML Schema that described the flowSpan element.

<xs:element name="flowSpan">
  <xs:complexType mixed="true">
    <xs:choice minOccurs="0" maxOccurs="unbounded">
      <xs:element ref="flowSpan"/>
      <xs:element ref="flowLine"/>
      <xs:element ref="flowRegionBreak"/>
    <xs:attributeGroup ref="PresentationAttrs"/>
    <xs:attributeGroup ref="StyleAttrs"/>

1.7 The flowRegionBreak element

The flowRegionBreak element causes the text to stop flowing into the current region and being flowing into the next region. If there is no next region, then the text will stop at the point of the flowRegionBreak.

The following is a extract of an XML Schema that described the flowRegionBreak element.

<xs:element name="flowRegionBreak">

1.8 The flowLine element

The flowLine element is used to force a line break in the text flow. The content following the end of a flowLine element will be placed on the next available strip in the flowRegion that does not already contain text. This happens even if the flowLine element has no children.

Note that if there are no printing characters between the end of multiple flowLine elements the second and greater flowLine elements have no effect as the current line does not contain any text when they are processed.

In all other aspects, the flowLine element is functionally equivalent to the flowSpan element.

The following is a extract of an XML Schema that described the flowLine element.

<xs:element name="flowLine">
  <xs:complexType mixed="true">
    <xs:choice minOccurs="0" maxOccurs="unbounded">
      <xs:element ref="flowSpan"/>
      <xs:element ref="flowLine"/>
      <xs:element ref="flowRegionBreak"/>
    <xs:attributeGroup ref="PresentationAttrs"/>
    <xs:attributeGroup ref="StyleAttrs"/>

1.9 The flowTref element

The flowTref element is used to insert the child text content of a referenced element. It's effect is analogous to the tref element.

The following is a extract of an XML Schema that described the flowTref element.

<xs:element name="flowTref">
    <xs:attribute ref="href" use="required"
    <xs:attributeGroup ref="PresentationAttrs"/>
    <xs:attributeGroup ref="StyleAttrs"/>

1.10 Text Flow

Text Flow is defined as a post processing step to the standard text layout model of SVG. This allows implementations to preserve existing code for text layout.

At a very high level this algorithm works by identifying word breaks in the original text using Unicode Standard Annex #14. Then the glyphs corresponding to words are taken in logical order and placed, in display order, on the current line (which may have several text regions). When the next word can not fit on the current line the algorithm moves to the next line, and calculates a new set of regions for text placement.

  1. Text layout is performed as normal, on one infinitely long line. The result is a set of positioned Glyphs.
  2. The text is then processed in logical order to determine line breaking opportunities between characters, according to Unicode Standard Annex #14 (http://www.unicode.org/unicode/reports/tr14)
  3. The flow region is examined to determine the available width of the first strip's, first text region.
  4. For each character in the text in logical order
    1. Get the glyph associated with the current character.
    2. If the current glyph has been placed already (ligatures) skip to the next char.
    3. If the current glyph is a printing character and will not fit on the line, then store the best line layout for this text region in the list of line layouts for this strip. If the updated list of line layouts is better than the best list of line layouts for the strip (based on number of characters) then it becomes the best list of line layouts for the strip.

      Processing backs up to the first character/glyph after the best line layout.

      Then iterate through the remaining text regions for this strip until one is found of sufficient width to hold the next glyph [word?] at which point processing continues.

      If no such text region is found then:

      1. Add the best list of line layouts for this strip to to the list of line layouts for the flow.
      2. Processing backs up to the first character/glyph after the last line layout in the best list of line layouts for this strip.
      3. Then construct a new strip based and corresponding text regions.
      4. If no new strip can be constructed (out of room in flow regions) then the current and all following glyphs are hidden and text layout stops.
    4. If the current glyph changes the height of the line-box (usually due to a change in font-size)
      1. Add the best line layout for this text region to the list of line layouts for this strip. If the updated list of line layouts for this strip is better than the best list of line layouts for the strip (based on number of characters) then it becomes the new best list of line layouts for the strip.
      2. Recalculate the strip and corresponding text regions. Then go back to the first character/glyph for this strip and start laying out text again.
    5. The current glyph is marked for inclusion in the current line layout.
    6. While the next char in the text (logical order) maps to the current glyph go to the next char (i.e. get to last char in a ligature). [ Should we do this??? ]
    7. If the current line layout is better than the current best line layout for this text region, replace it.

      A line layout (A) is considered better than another line layout (B), if A contains more characters than B, and if B ends with a break opportunity A must also end in a break opportunity.

      A Soft Hyphen can only be considered a break opportunity if the hyphen will fit.

    8. Loop and handle next character in text.
  5. For each Line layout in the list of line layouts
    1. Collapse the glyphs marked for inclusion on the current text region from the infinitely long line.
    2. Apply the text-align property.

The SVG Working Group actively encourages feedback on this algorithm, especially in relation to bidirectional text.

The following diagrams illustrate the above algorithm. Note that an SVG version of this diagram is available. This rasterization probably obscures the text on most displays.

diagram showing how glyphs are laid out along a single line before being placed into the flowRegion
diagram showing how bidi reordering is affected when laying out lines into the flowRegion
diagram showing the final results of text layout
(View the above diagrams in SVG)

1.11 Calculating Strips and Text Regions

In order to flow text into arbitrary regions it is necessary to calculate what portions of the object are available for text. SVG uses a fairly simple algorithm to do this. In summary you intersect the flow Region with the an infinitely wide line-box referred to below as the 'strip'. The result is then split into text regions where ever an edge from the flow region 'intrudes' into the line box.

The location and height of the line box must be provided, this is done for the first line by the 'first-line fitting alg' and subsequent lines follow the rules for inline formatting contexts (line-boxes stack).

Once the location of the line box in non-text progression direction is calculated the flow region is intersected by that line box clipping the segments of the path to the line box.

The bounding box is calculated for each of the clipped path segments. The left and right edges of the bounding boxes are sorted in order of increasing x (for equal x's left edges are considered less than right edges). The following pseudo code then generates the list of open areas for the current line.

        float start = 0;
        int   count = 1;

        // Skip the first edge since it must be a left edge.
        for (int i=1; i<numEdges; i++) {       
          if (edges[i].side == LEFT)  {
            // Left edge of BBox.  
            if (count == 0) {
              // End of an open region so record it.
              rgns.add(new LineBox(start, edges[i].loc));
          } else {
            // Right edge of a BBox.
            if (count == 0) {
              // Start of an 'open area' remember it.
              start = edges[i].loc;

This gives the regions of the strip that are unobstructed by flow region geometry, however those regions may be outside the flow region (such as in a hole, such as the middle of an 'O'). So the center of each rectangle should be checked to ensure it lies within the bounds of the flow region's geometry.

The final result is a list of regions available for the placement of text for that particular strip, these are called the 'text regions' for the strip. Note that for complex shapes there may be several text regions for a single strip.

All the text regions from a single strip are used before another strip is considered.

After the text regions are calculated the text-indent attribute is applied to the text-region if appropriate.

2. Integration with other XML formats

A number of relevant XML formats have matured since the time of the SVG 1.0 Recommendation. It is the intent of the SVG Working Group to allow easy integration with these formats, as well as to be a display format for generic XML.

2.1 Support for XForms

XForms [XForms] is a technology for describing forms in XML. It separates the model or content of the form from its presentation and is designed to be integrated into a host language, such as SVG. This provides the host language with an abstract definition of form content and leaves the rendering to the host. SVG is well suited to hosting XForms, since it provides powerful rendering and interactivity APIs.

Furthermore, a generic set of user interface components has been a common request from the SVG community. By describing how SVG and XForms can be integrated that request can be answered while providing more functionality if required. For example, the tight integration with a data model of a form should allow an SVG/XForms implementation to package SOAP messages easily. It also would allow an author to provide multiple interfaces to the same form (SVG, CSS, VoiceXML).

It also should be possible to extend generic form controls to use an SVG rendering specified by the document author. Events within the SVG rendering should be linked to behavior that updates the form model.

At the time of publication, the Working Group is undecided as to whether or not the SVG specification should describe a default rendering and behavior for some form elements, such as buttons and sliders. We realise that creating widget sets is a deep topic and specifically request feedback on this matter. Would a simple set of form widgets be sufficient in most situations, or would authors prefer to always create the SVG rendering and behaviour for every element?

2.2 Support for XML Events

XML Events [XMLEvents] is an XML syntax for integrating event listeners with DOM Event handlers. The events in SVG are hardwired into the language, such that you are required to embed the specification of event handling within the content (e.g. an element has an onclick attribute). By allowing XML Events, SVG content can specify the event listeners separately from the graphical content.

The specifics of what is meant by "allowing XML Events" is not yet clear. It may be that all event attributes from SVG 1.0/1.1 are deprecated in favor of XML events. Also, conformance has not yet been discussed - should all SVG viewers be required to support XML Events?

2.3 More SMIL Integration

SVG 1.0 included SMIL Animation for its animation syntax. It has been a common request from the public to have more features from SMIL in SVG. For that reason, SVG 1.2 will mostly likely incorporate more of SMIL, such as audio, video, transitions and enhanced timing controls.

The SVG Working Group may produce a W3C Note which defines an SVG+SMIL profile, similar to the XHTML+SMIL profile [XHTML+SMIL]. Alternatively, SVG could include more of the SMIL elements within the SVG namespace (e.g. the par, seq, audio and video elements).

SVG would probably not include SMIL Layout, Linking, Structure and MetaInformation. SVG might include parts of SMIL Media (audio and video), Content Control (test attributes related to Media), Timing and Synchronization (par, seq, excl elements as well as synchronization attributes). Time manipulation and transitions may be optional.

2.4 Rendering Arbitrary XML

Many of the enhancements to the SVG language are based on using SVG as a presentation layer for structured data (e.g. XForms). Public feedback has also suggested that many content developers are using SVG as the graphical user interface to their XML data, either through declarative transformations such as XSLT or through scripting (loading XML data into the SVG User Agent and transforming using the DOM).

The SVG Working Group is examining this use case closely, to see if there is anything that can be added to SVG in order to better facilitate this technique. While it is already possible today to use scripting to transform XML from a private namespace into SVG, the code has to be replicated in each SVG file and modified for each namespace. It may be possible to provide more support for a declarative syntax, similar to, or using parts of, XSLT.

The Working Group has not reached a conclusion on the requirements for such a feature. Should the mapping be one way or two way (ie. should there be a way to automatically reflect changes in the transformed content when the transformation is updated?) Should the feature be enabled by the styling system (ie. should you be able to apply a style rule that converts all myns:pie elements into a combination of svg:path elements?) Is this an extension to the 'use' element?

Again, a goal is to facilitate including semantically-rich XML content within the SVG file while having the SVG viewer render the XML. The user only need understand the XML and need not be concerned with the more complicated SVG content.

If a declarative syntax is used, SVG implementations may be required to support XPath and some simple XSLT features.

3. Printing

A Printing Profile for SVG is being developed by the SVG Working Group. At the present, the profile will probably be based on SVG Basic but some enhancements to the SVG language may be introduced in 1.2 to satisfy printing.

The SVG Working Group will first publish a requirements document for Printing. The early discussions in this area have shown a broad range of requirements, from SVG being intended as an XML format to describe graphics and printing workflow, to being a native format understood by a range of printing hardware.

Potential enhancements to the SVG language for printing include: a method to describe page layout (eg. a single SVG document that spans multiple pages, including information on orientation), better support for CYMK and SPOT colors, support for streaming (which may be limitations on SVG content to allow printers to control the allocation of resources - when they can throw away defined content) and enhanced compositing (described below, allowing the printer to perform compositing operations without rasterization).

4. Modifications to the Rendering Model

The SVG Working Group are considering a number of modifications to the rendering model for SVG 1.2. As the rendering model is perhaps the most important concept in the graphical representation of SVG content, any change to the model has to both fulfill a strong requirement and to be extremely carefully checked in order to not introduce inconsistencies, break existing content or have a substantial negative effect on implementations.

4.1 Enhanced Alpha Compositing

SVG 1.0 uses a simple rendering model, the Painter's Model, where a graphical object is composited onto the canvas above the objects that came before it in the document. While there is the ability to allow enhanced compositing within the filter system, there is no way to remove painting operations once they have been composited to the canvas. There are some usage scenarios where it would be advantageous to allow the enhanced compositing operations inline (ie. outside of the SVG 1.0 filter mechanism) since it may allow an implementation to perform the operation without rasterization. When placing graphical objects on the canvas, the result will be dependent on input color and opacity, the existing color and opacity on the canvas and the compositing operation. This will allow objects to remove "paint" from the canvas.

The actual technique that would allow such a feature is still under discussion. We propose three alternatives here, but make no guarantee that we will chose one. We strongly request feedback from the public on this feature.

The compositing operations under consideration are the 12 Porter-Duff operations [PORTERDUFF], 5 of which are implemented in the 'feComposite' element, the blending operations implemented by the 'feBlend' element and possibly a number of other operations (e.g. lightening colors, producing the color difference between the composited images). Other features under consideration are "Clip to Self" which restricts the compositing operation to the bounds of the graphical object, a behaviour common in the Java2D imaging model, and "Knockout Groups", the ability to remove parts of an object from rendering.

Repeating what was said above, modifications to the rendering model need to be carefully examined. Operations that may work well for simple objects may not map easily to complicated groups of objects. The SVG Working Group will attempt to meet at least the following requirements:

  1. Continuity: Small changes in parameters for compositing lead to small changes in the final visual result.
  2. Treat a group as an object: Any operation that can be done to a single element can be done to a group, and visa-versa.

Below are three alternatives for enhanced compositing.

Alternative 1: The 'comp-op' attribute

By adding an attribute, 'comp-op' to each rendering element (ie. the graphical elements plus the grouping elements) it would be possible to describe inline compositing operations.

  <rect x="10" y="10" width="30" height="30" fill="blue"/>
  <rect x="20" y="20" width="30" height="30" fill="red" 
     fill-opacity="0.5" comp-op="src-in"/>
  <g comp-op="multiply" opacity="0.7">
    <rect x="30" y="30" width="30" height="30" fill="green"/>
    <rect x="40" y="40" width="30" height="30" fill="red"/>

Alternative 2: The 'composite' group

The 'painters model' from SVG 1.0 is easily optimized. Since enhanced compositing is such a variation on the SVG 1.0 model, it may be better to define a special grouping operator that enables the richer compositing model. Only the elements of the 'composite' group are able to be composited in a manner other than directly on their background.

Alternative 3: Inline Filters

The SVG 1.0 language provides most of the required compositing operations, but does it through the filter model rather than allowing inline compositing. It may be possible to come up with a solution that allows a restricted set of filters to be placed inline with the rest of the SVG content (as opposed to referencing a predefined filter element when rendering an object).

<svg enable-background="new">
  <!-- whatever -->
  <feComposite op="src" x= y= width= height=>
      <path id="p" .../>
    <feGaussianBlur r=... >
      <feOffset dx= dy= >
        <use xlink:href="#p">
    <use xlink:href="#p">

4.2 Drawing Order

There have been a number of requests to provide a mechanism that separates drawing order from document order, a feature commonly referred to as "Z index". The SVG Working Group is evaluating the need for the feature as well as several possible solutions.

It is possible to simulate such a feature at the moment either using SMIL animation and multiple 'use' elements, or through scripting (moving an element toward the end of the document). However, both can place restrictions on document structure, and have limitations in the area of property inheritance.

The SVG Working Group requests feedback on this feature, especially any specific requirements you may have. SVG 1.2 plans to enable a drawing order independent of document order, a feature commonly referred to as Z index. This feature is in very early development - there are no further details at the moment.

5. Streaming

The SVG working group is considering streaming enhancements to the SVG language. Here are two identified uses for streaming:

6. Painting Enhancements

6.1 Color Element

The solidColor element is a paint server that provides a single color with opacity. It can be referenced like the other paint servers (gradients and patterns).

<xs:element name="solidColor">
    <xs:attributeGroup ref="PresentationAttrs"/>
    <xs:attributeGroup ref="StyleAttrs"/>

The solid-color property indicates what color to use for this solidColor element. The keyword currentColor and ICC colors can be specified in the same manner as within a <paint> specification for the fill and stroke properties.

Value: currentColor |
<color> [icc-color(<name>[,<icccolorvalue>]*)] |
Initial: black
Applies to: solidColor elements
Inherited: no
Percentages: N/A
Media: visual
Animatable: yes

The solid-opacity property defines the opacity of a given solid color.

Value: <alphavalue> | inherit
Initial: 1
Applies to: solidColor elements
Inherited: no
Percentages: N/A
Media: visual
Animatable: yes

6.2 Background Fill Property

SVG 1.2 will enable the author to specify a painting operation which will be used to fill the background of any element that creates a viewport, such as the root <svg> element.

We are still discussing if this paint operation should be restricted to a solid color or should allow any arbitrary paint operation, such as gradients and patterns. The arbitrary paint is the preferred option, but we have to precisely define what coordinate system to use, taking into account the aspect ratio and the canvas dimensions. It may not be the initial viewport that is filled. For now, we assume that we have worked this out and allow arbitrary paint.

The background-fill property defines the paint used to fill the viewport created by a particular element.

Value: <paint>
Initial: none
Applies to: viewport-creating elements
Inherited: no
Percentages: N/A
Media: visual
Animatable: yes

The current user coordinate system used when rendering the background is the user coordinate system in place on the given viewport-creating element before any additional transformations that might be specified on that element via a 'viewBox' or 'transform' attribute.

For the particular case of the viewport corresponding to the outermost 'svg' element (i.e., the initial viewport), the background is processed using the initial viewport coordinate system as the current user coordinate system. Thus, a background specified on the initial viewport will stay fixed relative to any zoom, pan and scroll actions by the user.

Note that 'background-fill' paints the entire viewport, not just that part which might include document contents due to the 'viewBox' attribute.

6.3 Transforming tspan

The current <tspan> element does not have a 'transform' attribute. This means that some animations of text are required to split related text chunks into separate text elements. By adding a 'transform' attribute, it should be possible to keep the related text content within one text element.

We will have to carefully examine what effect this has on the other attributes such as x, y, dx, dy and rotate, as well as the current text position.

7. DOM Enhancements

7.1 DOM Access to Images

There is an oversight in the SVG 1.0 DOM in that the SVGImage interface does not allow access to the DOM of the image it refers to (if that image is an SVG document). It should also be possible to access whatever DOM, if any, is provided by the non-SVG images. Examples could be an XML representation of the metadata associated with an image from a digital camera (e.g. EXIF) or other XML image formats.

To provide this functionality, SVG 1.2 will add a getImageDocument() method to the SVGImageElement interface. This method should return the Document DOM interface of the referenced image, if one is available. It is unlikely that the SVG specification will describe the format for the returned Document except in the case of a referenced SVG image.

Although the names of elements, interfaces and methods have been listed here, they are not yet finalized. The functionality will be added, however it may not be named exactly as specified above.

7.2 Conversion of Mouse Coordinates

It is quite difficult to convert the client space coordinates in a mouse event into the corresponding user space coordinates in the SVG document, taking into account nested viewBoxes, aspect ratio and the dimensions of the user agent. For this reason, SVG 1.2 will add convenience methods to the SVG DOM which provide the client space to user space coordinate conversion (and visa-versa).

7.3 DOM 3 Events

SVG 1.2 will most probably incorporate DOM Level 3 Events into SVG. The most significant change this entails is the addition of Text Events (ie. events that encapsulate some form of textual content, such as a keypress).

7.4 Window Interface

The majority of scripted SVG documents in existence make use of the browser specific Window interface, which includes methods such as setTimeout and clearInterval. SVG 1.2 will most likely specify an SVGWindow interface, taking into account the defacto standard that already exists.

A method will be added to the SVGDocument interface to enable access to the SVGWindow interface. The following is the current proposed Window interface in IDL.

Interface SVGWindow

Interface SVGWindow provides a global object for scripts embedded in a SVG document.

IDL Definition
interface SVGWindow { 

  readonly  attribute StyleSheet    defaultStyleSheet
  readonly  attribute SVGDocument   document
  readonly  attribute Event         evt
  readonly  attribute long          innerHeight
  readonly  attribute long          innerWidth
  attribute DOMString     src

  void              clearInterval ( in object interval );
  void              clearTimeout ( in object timeout );
  void              getURL ( in DOMString uri, in EventListener callback );	
  DocumentFragment  parseXML ( in DOMString source, in Document document );
  void              postURL ( in DOMString uri, in DOMString data, in EventListener callback,
  in DOMString mimeType, in DOMString contentEncoding );
  DOMString         printNode ( in Node node );
  Object            setInterval ( in DOMString code, in long delay );
  Object            setTimeout ( in DOMString code, in long delay );

interface SVGDocument { 

  readonly  attribute SVGWindow     window


readonly StyleSheet defaultStyleSheet
The user agent style sheet.
readonly SVGDocument document
The SVGDocument.
readonly Event evt
The event currently being dispatched. Null if there is no currently processed event.
readonly long innerHeight
Viewport height in pixels.
readonly long innerWidth
Viewport width in pixels.
DOMString src
The URI of the current document. On setting, the new document pointed to by the URI is loaded by the user agent.
Cancels a time-out that was set with the setInterval method.
in object interval An object that specifies the time-out setting returned by a previous call to the setInterval method
No Return Value
No Exceptions
Cancels a time-out that was set with the setTimeout method.
in object timeout An object that specifies the time-out setting returned by a previous call to the setTimeout method.
No Return Value
No Exceptions
Gets some data from the server the document was served from.
in DOMString url The URI reference for the data to be loaded.
in EventListener callback The method to be invoked when the data has been fully loaded.
No Return Value
No Exceptions
Converts a string into a DocumentFragment.
in DOMString source A string containing a XML document fragment.
in Document document The Document context for parsing the XML fragment.
Return Value
DocumentFragment An XML Fragment converted from the original DOMString.
No Exceptions
Sends some data to the server the document was served from.
in DOMString url The URI reference of the application that will receive the data.
in DOMString data The data to be sent to the server.
in EventListener callback The method to be invoked when the data has been fully loaded.
in DOMString mimeType MIME type to be reported to the server.
in DOMString contentEncoding Encoding to be used.
No Return Value
No Exceptions
Converts a Node into a DOMString.
in Node node The Node to be converted.
Return Value
DOMString A serialized version of the original Node.
No Exceptions
Evaluates an expression after a specified number of milliseconds has elapsed.
in DOMString code A string that indicates the code to be executed when the specified interval has elapsed.
in long delay An integer that specifies the number of milliseconds.
Return Value
object An object that is used to cancel the interval with the setInterval method.
No Exceptions
Evaluates an expression after a specified number of milliseconds has elapsed.
in DOMString code A string that indicates the code to be executed when the specified interval has elapsed.
in long delay An integer that specifies the number of milliseconds.
Return Value
object An object that is used to cancel the timeout with the setTimeout method.
No Exceptions

8. Other new features

8.1 Navigating between elements

SVG 1.2 plans to add the ability to navigate between elements using an input device, such as a keyboard. In order to do this, the specification will describe what it means to focus on an element (text or graphical), as well as provide a language feature that allows the author to specify the order of navigation, which may be independent of the document order.

These features are useful in a number of applications, including accessibility and user interfaces.

The most likely solution for specifying navigation order is to add a navIndex attribute, similar to XForms, or a nav-index property.


"Compositing Digital Images", T. Porter, T. Duff, SIGGRAPH '84 Conference Proceedings, Association for Computing Machinery, Volume 18, Number 3, July 1984.
"XForms 1.0", M. Dubinko, L. Klotz, R. Merrick, T.V. Raman, W3C Candidate Recommendation 12 November 2002
See http://www.w3.org/TR/xforms/
"XHTML+SMIL Profile", D. Newman, A. Patterson, P. Schmitz, W3C Note 31 January 2002
See http://www.w3.org/TR/XHTMLplusSMIL/
"XML Events", S. McCarron, S. Pemberton, T.V. Raman, W3C Working Draft 12 August 2002
See http://www.w3.org/TR/xml-events/


The authors of this specification are the participants of the W3C SVG Working Group.

  • Ola Andersson, ZOOMON AB
  • Henric Axelsson, Ericsson AB
  • Phil Armstrong, Corel Corporation
  • Benoît Bézaire, Corel Corporation
  • Craig Brown, Canon Information Systems Research Australia
  • Mike Bultrowicz, Savage Software
  • Tolga Capin, Nokia Inc.
  • Mathias Larsson Carlander, Ericsson AB
  • Jakob Cederquist, ZOOMON AB
  • Charilaos Christopoulos, Ericsson AB
  • Lee Cole, Quark
  • Don Cone, America Online Inc.
  • Alex Danilo, Canon Information Systems Research Australia
  • Thomas DeWeese, Eastman Kodak
  • Jon Ferraiolo, Adobe Systems Inc.
  • Darryl Fuller, Schema Software
  • 藤沢 淳 (FUJISAWA Jun), Canon
  • Rick Graham, BitFlash
  • Vincent Hardy, Sun Microsystems Inc.
  • 端山 貴也 (HAYAMA Takanari), KDDI Research Labs
  • Lofton Henderson, OASIS
  • 石川 雅康 (ISHIKAWA Masayasu), W3C
  • Dean Jackson, W3C/CSIRO (W3C Team Contact)
  • Christophe Jolif, ILOG S.A.
  • Lee Klosterman, Hewlett-Packard
  • 小林 亜令 (KOBAYASHI Arei), KDDI Research Labs
  • Thierry Kormann, ILOG S.A.
  • Yuri Khramov, Schema Software
  • Chris Lilley, W3C (Working Group Chair)
  • Philip Mansfield, Schema Software
  • 水口 充 (MINAKUCHI Mitsuru), Sharp Corporation
  • Luc Minnebo, Agfa-Gevaert N.V.
  • 小野 修一郎 (ONO Shuichiro), Sharp Corporation
  • Antoine Quint, Fuchsia Design (formerly of ILOG)
  • 相良 毅 (SAGARA Takeshi), KDDI Research Labs
  • Brad Sipes, ZOOMON AB
  • Peter Sorotokin, Adobe Systems Inc.
  • 上田 宏高 (UEDA Hirotaka), Sharp Corporation
  • Rick Yardumian, Canon Development Americas
  • Charles Ying, Openwave Systems, Inc.