SVG Integration 1.0

1 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.

1.1 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

2 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

3 Foreign Content in 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 in SVG, by reference or by inclusion (inline), as with the ‘foreignObject’ element described in embedding foreign object types.

3.1 'foreignObject' Element

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

For example, if HTML content is included inline in SVG inside a ‘foreignObject’ element with a width of 400 and a height of 600, the HTML content will wrap to that area, as if it were an HTML @@ unknown name 'div' element with those dimensions.

@@ What should we say about when to rasterize the foreign content? In existing implementations, HTML form controls in 'foreignObject' often look pixelated

@@ Add examples of HTML in foreignObject, by reference and inline.

@@ Link to CDR\WICD specs.

4 SVG in Foreign Content

SVG is designed to be used as a standalone format, or in combination with other formats such as X/HTML. SVG can be used in these different formats, by reference or by inclusion (inline).

When used as a reference, SVG content falls into one of the categories detailed in Referencing Modes for SVG. When used as inline, SVG must be used with the constraints established by that host language (such as HTML5).

@@ Add examples of referenced and inline SVG.

@@ Give details about link target keywords in inline and referenced modes.

@@ Link to CDR\WICD specs.

5 Extending SVG

5.1 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.

5.2 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>

  

6 SVG Encoding

6.1 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?

6.2 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.

7 SVG Elements, Attributes, and Properties

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.

7.1 Case Matching

For purposes of string matching and conversion, such as post-parsing case-fixing, the Element Name must 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.

7.2 SVG Elements

7.3 SVG Attributes