SVG Integration 1.0

Introduction

Describe the technology and specification here.

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.

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.

Use Cases and Requirements

This section is informative.

Here are some of the use cases and requirements for this specification.

• must have clear tables that integrate all known SVG elements, attributes, attribute values, and methods
• should link back to normative definitions for all the above
• should be automated (derive lists from SVG 1.1, SVG Tiny 1.2, Vector Effects, Filters, Compositing, Transforms, etc. via script)
• must be normatively referenceable, e.g. by HTML5, CSS, ODF, IPTV, and other languages where we expect SVG might be reused as a whole, or even referenced in part, as in the Widgets specs
• should have revision history [1]
• may have case-insensitive string equivalents [2]
• must cover different embedding and referencing scenarios (may work with HTML & CSS WGs here), with different expected capabilities
• must explain how to extend SVG properly (copying the chapter from SVG Tiny 1.2) [4]
• must address potential security issues (external references, circular references, that weird thing ROC brought up with pixel-sniffing)
• must address passed in parameters, fragment identifiers, etc.
• should cover other specific odds and ends with various elements
• must address focus navigation across embedding boundaries
• must address fragment identifiers behavior for compound documents
• must address link traversal in compound documents
• must discuss transparency and compositing
• should discuss embedding size and dimensions (including script access to rendered dimensions)
• may introduce new integration features
• may define parameter defaulting syntax
• may define or reference a data binding mechanism

Referencing Modes for SVG

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?

Examples

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

Foreign Content and SVG

SVG is designed to be used as a standalone format, or in combination with other formats such as X/HTML. These different formats can be used by reference, as detailed in Referencing Modes for SVG, or inline, as with the 'foreignObject' element described in embedding foreign object types.

'foreignObject' Element

When 'foreignObject' is used to contain content which is styled by CSS, the viewport establishes the initial containing block. The dimensions of the CSS viewport in pixels are the width and height attribute values of the 'foreignObject' element in user units.

Extending SVG

Extension conformance requirements

Specifications and implementations are allowed to extend the SVG specification but in order to claim conformance the following criteria need to be met:

• An extension must support the normative chapters of the SVG specifications that define conformance to SVG.
• An extension must support the normative chapters of the SVG specifications that detail extensibility.
• An extension must support the normative chapters of the SVG specifications that define conditional processing.
• If using features defined in SVG, an extension must not redefine the syntax of those features.
• An extension must not redefine the semantics of any existing SVG element or attribute.
• SVG attribute and element names must not be reused in extensions, even in a separate namespace, in order to avoid author confusion.

Foreign namespaces and private data

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:

• Application-specific information to allow authoring applications to include model-level data in the SVG content to serve their "roundtripping" purposes (i.e., the ability to write, then read a file without loss of higher-level information).
• Supplemental data for extensibility. For example, suppose you have an extrusion extension which takes any 2D graphics and extrudes it in three dimensions. When applying the extrusion extension, you probably will need to set some parameters. The parameters can be included in the SVG content by inserting elements from an extrusion extension namespace.
• Metadata to add supplementary semantics to the SVG file, or to specific elements or attributes within the file.

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>

  

SVG Encoding

XML encoding conformance requirements

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?

Non-XML encoding conformance requirements

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.

SVG Elements Table

This is a comprehensive list of all SVG elements from the SVG 1.1 [SVG11] and SVG Tiny 1.2 [SVGT12] specifications. This document will be updated as new elements are minted.

For purposes of string matching and conversion, such as post-parsing case-fixing, the Element Name shall represent the canonical string. If an implementation finds a case-insensitive string match for any of these element name which contains characters in the range U+0041..U+005A (Unicode class Lu), the equivalent characters in the range U+0061..U+007A (Unicode class Ll) must be converted to the equivalent class Lu character. In other words, for mixed-case element names, the lowercase-only strings must be changed to the mixed-case string.

Element Name

Column containing the element names. All elements are in the SVG namespace, except for 'listener' which is in the XML Events namespace.

Attributes

For each element, this lists the attributes which may occur on it. Note that these are only the attributes and not the properties.

Properties

This column indicates whether or not the given element may receive properties. There are several options:

✔

All properties defined in this specification can be set as attributes on the given element.

✘

None of the properties defined in this specification can be set as attributes on the given element.

M

Only the properties in the SVG Tiny 1.2 media group can be set on this given element. The media group is a subset of the properties that is meaningful on media elements and does not cause the 'fill' property to clash with the 'fill' SMIL attribute. The media group comprises the following properties: 'audio-level', 'buffered-rendering', 'display', 'image-rendering', 'pointer-events', 'shape-rendering', 'text-rendering', 'viewport-fill', 'viewport-fill-opacity', and 'visibility'.

Possible Children

Lists the elements that can occur as children of the given element.

[character data]

Indicates that character data can occur as the child of a given element.

N/A

Indicates that the element, and its associated attributes and properties, are not defined in that particular specification.

SVG Attributes

This is a comprehensive list of all SVG attributes from the SVG 1.1 [SVG11] and SVG Tiny 1.2 [SVGT12] specifications.

Insert table here, with links to attributes definitions in all relevant specs, and permitted attribute values and applicable elements.

RelaxNG Schema for SVG Integration 1.0

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.

References

Normative References

[RFC2119]

Key words for use in RFCs to Indicate Requirement Levels, S. Bradner, March 1997.
Available at http://tools.ietf.org/html/rfc2119.

[SVG11]

Scalable Vector Graphics (SVG) 1.1, J. Ferraiolo, 藤沢 淳 (Fujisawa Jun), D. Jackson, eds. World Wide Web Consortium, 14 January 2003.
This edition of SVG 1.1 is http://www.w3.org/TR/2003/REC-SVG11-20030114/.
The latest edition of SVG 1.1 is available at http://www.w3.org/TR/SVG11/.

[SVGT12]

Scalable Vector Graphics (SVG) Tiny 1.2, O. Andersson, R. Berjon, E. Dahlström, A. Emmons, J. Ferraiolo, A. Grasso, V. Hardy, S. Hayman, D. Jackson, C. Lilley, C. McCormack, A. Neumann, C. Northway, A. Quint, N. Ramani, D. Schepers, A. Shellshear, eds. World Wide Web Consortium, 22 December 2008.
This edition of SVG Tiny 1.2 is http://www.w3.org/TR/2008/REC-SVGTiny12-20081222/.
The latest edition of SVG Tiny 1.2 is available at http://www.w3.org/TR/SVGTiny12/.

Informative References

[NVDL]

Information Technology — Document Schema Definition Languages (DSDL) — Part 4: Namespace-based Validation Dispatching Language: ISO/IEC FDIS 19757-4:2005(E), International Organization for Standardization, December 2005.
Available at http://www.jtc1sc34.org/repository/0694.pdf.

[SCHEMA2]

XML Schema Part 2: Datatypes Second Edition. P. Biron, A. Malhotra, eds. World Wide Web Consortium, 28 October 2004. (See also Processing XML 1.1 documents with XML Schema 1.0 processors [XML11-SCHEMA].)
This edition of XML Schema Part 2 is http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/.
The latest edition of XML Schema Part 2 is available at http://www.w3.org/TR/xmlschema-2/.

Acknowledgments

The editors would like to acknowledge and thank the following people for substantive aid with this specification: Erik Dahlström.