SVG Integration Module Level 1

Abstract

This specification provides referencing modes and the respective fetching policies for SVG. Furthermore it gives guidance for host languages and applications or devices with special needs by providing different referencing modes for SVG.

Status of this document

Table of contents

1 Introduction

This section is informative.

SVG is a vector graphic markup language to express art work and to create interactive, content rich applications. The vector graphics is described by geometry primitives like <circle>, <rect> or <path>. Furthermore, SVG describes SVG resources like <linearGradient> and <pattern> but also <mask> and <filter>. SVG makes use of image references, stylesheets like CSS, allows scripting with JavaScript and declarative animations with CSS Transitions, CSS Animations and SVG Animations giving it its actual strength. Geometries, SVG resources, stylesheets and scripts can be modularized and referenced.

In the last years, user agents were confronted with several attacking patterns to reveal privacy data of users. These attacks lead to a new understanding of the protection of privacy for the web platform. This specification extends SVG with existing security mechanisms to protect the privacy of the user.

SVG can also be used in a lot of different situations. Some might not be suited for devices or use cases with special needs. The section "Available features by referencing mode" provides a guidance with several predefined modes that combine certain features.

Examples for different devices/use cases missing.

The specification is also meant to be a reference for all SVG elements, SVG attributes and CSS properties used or defined by all SVG recommendations.

2 Module interactions

This specification extends the W3C recommendations SVG 1.1 [SVG11], SVG 1.2 Tiny [SVGT12] and future recommendations of SVG. Furthermore, this specification provides a security model for referencing SVG and is meant to be a normative reference for every host language embedding SVG.

3 Referencing modes

SVG is a markup language that can be fetched and displayed as a root document. Furthermore, it can also be referenced or embedded by another host language such as HTML. This following document referencing modes apply:

SVG embedding mode

The SVG document is embedded in a nested browsing context of a host language such as the <iframe> tag or the <object> tag in HTML or integration points such as for the <embed> tag in HTML or the <foreignObject> element in SVG.

Note: The <object> tag treats external resources as either a nested browsing context or as an image. SVG documents are always treated as a nested browsing context.

Research the behavior on referencing SVG by <embed>. Is it less restrictive than <object>?

Inline SVG mode

The host language can define an integration point to embed SVG as part of its own document. Scripts, styles and the global time line are shared between the document of the host language and the included SVG markup. Both, the SVG markup and the host languages markup share the same document context. Events, such as "onload" rely on the event handling of the host language.

Events might not depend on host language to fire onload event.

SVG resource mode

Stylesheets such as CSS can reference certain parts of an SVG document by fragment identifiers. Often these SVG documents need to be fetched to serve as a source of resources.

SVG image mode

A host language such as HTML or CSS can reference SVG documents as images.

4 Fetching

Fetching is the process of loading and processing requested resources. Depending on the used document referencing mode, one of the following fetching policies apply:

Add fetching modes based on the fetching algorithm from HTML5

SVG not tainting canvas all the time

5 Available features by referencing mode

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

6.1 SVG Elements

Add all SVG elements and the usage in specs.

6.2 SVG Attributes

Add all SVG attribtues and the usage in specs.

6.3 Properties

Add all CSS properties defined by SVG specs.

Acknowledgments

Thanks to Erik Dahlström for the help, careful reviews, comments, and corrections.

Conformance

Document conventions

Conformance requirements are expressed with a combination of descriptive assertions and RFC 2119 terminology. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in the normative parts of this document are to be interpreted as described in RFC 2119. However, for readability, these words do not appear in all uppercase letters in this specification.

All of the text of this specification is normative except sections explicitly marked as non-normative, examples, and notes. [RFC2119]

Examples in this specification are introduced with the words "for example" or are set apart from the normative text with class="example", like this:

Informative notes begin with the word "Note" and are set apart from the normative text with class="note", like this:

Note, this is an informative note.

Conformance classes

Conformance to this specification is defined for three conformance classes:

style sheet

A CSS style sheet.

renderer

A UA that interprets the semantics of a style sheet and renders documents that use them.

authoring tool

A UA that writes a style sheet.

A style sheet is conformant to this specification if all of its statements that use syntax defined in this module are valid according to the generic CSS grammar and the individual grammars of each feature defined in this module.

A renderer is conformant to this specification if, in addition to interpreting the style sheet as defined by the appropriate specifications, it supports all the features defined by this specification by parsing them correctly and rendering the document accordingly. However, the inability of a UA to correctly render a document due to limitations of the device does not make the UA non-conformant. (For example, a UA is not required to render color on a monochrome monitor.)

An authoring tool is conformant to this specification if it writes style sheets that are syntactically correct according to the generic CSS grammar and the individual grammars of each feature in this module, and meet all other conformance requirements of style sheets as described in this module.

Partial implementations

So that authors can exploit the forward-compatible parsing rules to assign fallback values, CSS renderers must treat as invalid (and ignore as appropriate) any at-rules, properties, property values, keywords, and other syntactic constructs for which they have no usable level of support. In particular, user agents must not selectively ignore unsupported component values and honor supported values in a single multi-value property declaration: if any value is considered invalid (as unsupported values must be), CSS requires that the entire declaration be ignored.

Experimental implementations

To avoid clashes with future CSS features, the CSS2.1 specification reserves a prefixed syntax for proprietary and experimental extensions to CSS.

Prior to a specification reaching the Candidate Recommendation stage in the W3C process, all implementations of a CSS feature are considered experimental. The CSS Working Group recommends that implementations use a vendor-prefixed syntax for such features, including those in W3C Working Drafts. This avoids incompatibilities with future changes in the draft.

Non-experimental implementations

Once a specification reaches the Candidate Recommendation stage, non-experimental implementations are possible, and implementors should release an unprefixed implementation of any CR-level feature they can demonstrate to be correctly implemented according to spec.

To establish and maintain the interoperability of CSS across implementations, the CSS Working Group requests that non-experimental CSS renderers submit an implementation report (and, if necessary, the testcases used for that implementation report) to the W3C before releasing an unprefixed implementation of any CSS features. Testcases submitted to W3C are subject to review and correction by the CSS Working Group.

Further information on submitting testcases and implementation reports can be found from on the CSS Working Group’s website at http://www.w3.org/Style/CSS/Test/. Questions should be directed to the public-css-testsuite@w3.org mailing list.

References

Normative References

Informative References

Index

Property index

Issues Index