Copyright © 2004 W3C® (MIT, ERCIM, Keio), All Rights Reserved. W3C liability, trademark, document use and software licensing rules apply.
The SVG Integration Module is intended as a guide to other markup and programming on how to best integrate SVG, within the context of that language's constraints. SVG may be integrated in whole or in part, and may be included in another language by reference or by inclusion (that is, through linking or inline). This specification contains normatively referenceable material, and discusses default behaviors and best practices, but is not intended to override the design of the referencing language.
This specification contains references to other SVG specifications.
This section describes the status of this document at the time of its publication. Other documents may supersede this document. The latest status of this document series is maintained at the W3C.
This document has been produced by the W3C SVG Working Group as part of the W3C Graphics Activity within the Interaction Domain.
We explicitly invite comments on this specification. Please send them to www-svg@w3.org (archives), the public email list for issues related to vector graphics on the Web. Acceptance of the archiving policy is requested automatically upon first post to either list. To subscribe to this list, please 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.
This draft of SVG Integration introduces new normative prose for integrating the SVG language into other markup languages. One of the goals is that this specification can be re-used more easily by other specifications that want to have well-defined interaction and interoperability with SVG. Future drafts of this specification may introduce syntax and markup for the SVG language that may not be backwards compatible with older SVG User Agents, and the use of this syntax should be accompanied by a fallback using the 'switch' element.
The main purpose of this document is to encourage public feedback. The best way to give feedback is by sending an email to www-svg@w3.org. Please include in the subject line of your message the string "[Integration]", and a short keyword that identifies the area of the specification the comment is referring to (e.g "[Integration] Section X.Y - Foo attribute values"). If you have comments on multiple areas of this document, then it is probably best to split those comments into multiple messages.
The public are welcome to comment on any aspect in this document, but there are a few areas in which the SVG Working Group are explicitly requesting feedback. These areas are noted in place within this document. There is also a specific area related to the specification that is listed here:
SVG is a language for describing two-dimensional graphics in XML [XML10, XML11]. SVG is designed to allow easy integration into other languages, in particular other XML-based Web languages. However, other languages do not need to be in canonical XML format to integrate SVG; for example, SVG may be used inline or by reference in HTML.
In defining individual languages that can be used together, there are often points of integration, such as usage scenarios, APIs, and other details that do not follow from either language alone. This specification is intended to provide normative recommendations for integration into other languages to clarify implementation and provide maximum author and user functionality.
Note that even though this specification references parts of SVG 1.1 and SVG Tiny 1.2 it does not require a complete implementation of those specifications.
This document is normative, except those sections explicitly pointed out as informative.
This document contains explicit conformance criteria that overlap with some RNG definitions in requirements. If there is any conflict between the two, the explicit conformance criteria are the definitive reference.
This section is informative.
Here are some of the use cases and requirements for this specification.
Should this document make conformance criteria on implementations, on documents, on other languages, or some combination?
There are many different ways in which an external SVG file may be referenced in a host language. These different scenarios are known as referencing modes, and each referencing mode is suited to a different set of constraints, in terms of security, performance optimization, intended usage, and legacy considerations. Each referencing mode defines whether such features as script execution, external references, declarative animation, interactivity, and linking must or must not be supported. Different referencing modes may be specified for different aspects of the same language, or a language may use a single referencing mode, depending on the complexity of the language. A conforming User Agent must support the full feature set defined for each referencing mode for all languages that that User Agent supports, and must not permit behavior disallowed by the relevant referencing mode. Where multiple referencing modes are permitted, authors should choose the most restricted referencing mode that meets their needs.
A DOM must be produced and maintained for SVG images using all referencing modes except Immediate Mode, and the DOM must be exposed to Accessibility Technology User Agents. Should we have an Immediate Mode?
Should we talk about CORS here?
Should focus traversal be a referencing mode feature?
An external reference is any link from the current file to another file for inclusion, rendering, or processing in the context of the current file. In some situations, external references may constitute a security concern; because it is difficult to detect when the use of an external resource is safe and when it is not, under secure circumstances, all external references should be disabled, unless there is an appropriate security mechanism in place (CORS?). External references include, but are not limited to:
This referencing mode imposes no restrictions on any feature of the SVG language. This is the referencing mode that must be used for standalone SVG files in normal circumstances. This specification recommends that this referencing mode apply to those elements that are referred to in HTML5 as a browsing context, such as the <object>, <iframe>, and <embed> elements.
| Dynamic Interactive Features | |
|---|---|
| script execution | yes |
| external references | yes |
| declarative animation | yes |
| interactivity | yes |
| link traversal | yes |
This referencing mode is intended for circumstances where performance may be an issue, where there are limited security concerns, or where image support has traditionally been limited to raster images (such as JPEG or PNG), but where animation is desired. Animated mode allows declarative animation, but permits no script execution, interactivity, or link traversal. This is the referencing mode that must be supported for the SVG <image> element and is recommended to apply to the HTML <img> element and for use as a Widget icon.
| Animated Features | |
|---|---|
| script execution | no |
| external references | yes |
| declarative animation | yes |
| interactivity | no |
| link traversal | no |
This referencing mode is intended for circumstances where performance may be an issue, where there are strict security concerns, or where image support has traditionally been limited to raster images (such as JPEG or PNG), but where animation is desired. Secure animated mode allows declarative animation, but permits no script execution, external references, interactivity, or link traversal.
| Secure Animated Features | |
|---|---|
| script execution | no |
| external references | no |
| declarative animation | yes |
| interactivity | no |
| link traversal | no |
This referencing mode is intended for circumstances where performance may be an issue, or where there are limited security concerns. Static mode permits no script execution, declarative animation, interactivity, or link traversal. This is the referencing mode that is recommended to apply to CSS background images.
| Static Features | |
|---|---|
| script execution | no |
| external references | yes |
| declarative animation | no |
| interactivity | no |
| link traversal | no |
This referencing mode is intended for circumstances where performance may be an issue, or where there are strict security concerns. Secure static mode permits no script execution, external references, declarative animation, interactivity, or link traversal.
| Secure Static Features | |
|---|---|
| script execution | no |
| external references | no |
| declarative animation | no |
| interactivity | no |
| link traversal | no |
This referencing mode is intended for circumstances where performance is a major concern. Immediate mode permits no script execution, external references, declarative animation, interactivity, or link traversal. In addition, a User Agent may to discard the DOM representation from memory after rendering. This is only to be used in extreme circumstances, as it severely limits the usability and accessibility of SVG. Should we have an Immediate Mode?
| Immediate Features | |
|---|---|
| script execution | no |
| external references | no |
| declarative animation | no |
| interactivity | no |
| link traversal | no |
Below are various methods of embedding SVG in an HTML page by reference. Each referencing mode element should display a yellow smiley face. In each example below, clicking on the eyes tests link traversal, and clicking on the face tests declarative interactivity and script execution. The link should replace the image with a blue square (clicking on that will return you to the original image). The declarative (SMIL) interactivity should change the image from shades of yellow to shades of green. The script should fill in the smile. Time-based (as opposed to interactivity-based) declarative animation is supported if the left eye is winking.
| Example 1: Different referencing modes in HTML | ||||
|---|---|---|---|---|
| object | iframe | embed | img | CSS background |
 |
||||
Specifications and implementations are allowed to extend the SVG specification but in order to claim conformance the following criteria need to be met:
SVG allows inclusion of elements from foreign namespaces anywhere with the SVG content. In general, the SVG user agent must include any unknown elements in the DOM, but must otherwise ignore unknown elements. (The notable exception is described under Embedding foreign object types.)
Extension elements in the SVG namespace must not be used.
Additionally, SVG allows inclusion of attributes from foreign namespaces on any SVG element. Extensions of SVG-namespaced elements in the form of attributes must be bound to a namespace by a prefix. Any unbound attributes not defined by an SVG specification must be treated as unknown attributes. The SVG user agent must include unknown attributes in the DOM, but may otherwise ignore unknown attributes. Attributes bound to a foreign namespace may extend the semantics or behavior of SVG elements in user agents that support that foreign namespace.
SVG's ability to include foreign namespaces can be used for the following purposes:
To illustrate, a business graphics authoring application might want to include some private data within an SVG document so that it could properly reassemble the chart (a pie chart in this case) upon reading it back in:
<?xml version="1.0"?>
<svg xmlns="http://www.w3.org/2000/svg" version="1.2" baseProfile="tiny"
width="4in" height="3in">
<defs>
<myapp:piechart xmlns:myapp="http://example.org/myapp"
title="Sales by Region">
<myapp:pieslice label="Northern Region" value="1.23"/>
<myapp:pieslice label="Eastern Region" value="2.53"/>
<myapp:pieslice label="Southern Region" value="3.89"/>
<myapp:pieslice label="Western Region" value="2.04"/>
<!-- Other private data goes here -->
</myapp:piechart>
</defs>
<desc>This chart includes private data in another namespace</desc>
<!-- In here would be the actual SVG graphics elements which
draw the pie chart -->
</svg>
@@ Address getBBox() and other methods in context of content in 'foreignObject'
An SVG Document Fragment, SVG Stand-Alone Document, or SVG Included Document encoded using XML conforms to the SVG specifications if it is valid, well-formed, and uses namespaces according to the Namespaces in XML specification. Non-conforming documents may be rendered according to the behavior specified for error-correction in the SVG or XML specifications. Which SVG spec should define better error handling?
An SVG Document Fragment, SVG Stand-Alone Document, or SVG Included Document encoded using a non-XML encoding (e.g. efficient XML compression, or HTML5 parser) conforms to the SVG specifications if and only if the non-XML encoding in question guarantees roundtripping from XML to the encoding and back in such a way that the resulting document when processed by an SVG user agent must always render, animate, and interact in the exact same way as the original. Note that this requires a high-level of fidelity from the encoding including, but not limited to, the ability to encode non-conforming content and content from foreign namespaces without loss, maintaining ID typing, and not removing non-rendered elements such as 'title', 'desc', 'metadata', or elements not included in the rendering tree through use of conditional processing attributes.
This is a comprehensive list of all SVG elements from the SVG 1.1 [SVG11] and SVG Tiny 1.2 [SVGT12] specifications.
| Element | Attributes | Properties | Possible Child Elements | ||||||
|---|---|---|---|---|---|---|---|---|---|
| SVG 1.1 | SVGT 1.2 | SVG 2.0 | SVG 1.1 | SVGT 1.2 | SVG 2.0 | SVG 1.1 | SVGT 1.2 | SVG 2.0 | |
| feComponentTransfer | foo | foo | foo | foo | foo | foo | foo | foo | foo |
This is a comprehensive list of all SVG attributes and properties from the SVG 1.1 [SVG11] and SVG Tiny 1.2 [SVGT12] specifications.
| Attribute or Property | Type | Animatable | Inheritable | Values | Applicable Elements | ||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| SVG 1.1 | SVGT 1.2 | SVG 2.0 | SVG 1.1 | SVGT 1.2 | SVG 2.0 | SVG 1.1 | SVGT 1.2 | SVG 2.0 | SVG 1.1 | SVGT 1.2 | SVG 2.0 | ||
| foo | foo | foo | foo | foo | foo | foo | foo | foo | foo | foo | foo | foo | foo |
The schema for SVG Integration 1.0 is written in RelaxNG [RelaxNG], a namespace-aware schema language that uses the datatypes from XML Schema Part 2 [Schema2]. This allows namespaces and modularity to be much more naturally expressed than using DTD syntax. The RelaxNG schema for SVG Filter 1.2 may be imported by other RelaxNG schemas, or combined with other schemas in other languages into a multi-namespace, multi-grammar schema using Namespace-based Validation Dispatching Language [NVDL].
Unlike a DTD, the schema used for validation is not hardcoded into the document instance. There is no equivalent to the DOCTYPE declaration. Simply point your editor or other validation tool to the IRI of the schema (or your local cached copy, as you prefer).
The RNG is under construction, and only the individual RNG snippets are available at this time. They have not yet been integrated into a functional schema. The individual RNG files are available here.
The following interfaces are defined below: RandomInterface.
The RandomInterface interface corresponds to the 'RandomInterface' element.
interface RandomInterface : SVGElement {
readonly attribute InterfaceString foo;
};
The editors would like to acknowledge and thank the following people for substantive aid with this specification: Erik Dahlström.