SVG Static

Editor’s Draft,

This version:
http://www.w3.org/TR/svg-static
Feedback:
www-svg@w3.org with subject line “[svg-static] … message topic …” (archives)
Issue Tracking:
Inline In Spec
Editors:
(Apple Inc)
(Adobe)

Copyright © 2019 W3C® (MIT, ERCIM, Keio, Beihang). W3C liability, trademark and document use rules apply.
This document includes material copied from or derived from the Scalable Vector Graphics (SVG) 1.1 Specification. Copyright 2011 W3C® (MIT, ERCIM, Keio, Beihang). It is subject to the W3C Software Document Notice and License.

Abstract

SVG Static is a profile of SVG 1.1 designed for interoperability with static apps and system libraries that execute outside the Web environment, and thus cannot rely on features such as linking, interactivity, animation, or the Web security model.

Status of this document

This section describes the status of this document at the time of its publication. Other documents may supersede this document. A list of current W3C publications and the latest revision of this technical report can be found in the W3C technical reports index at http://www.w3.org/TR/.

This document is the 12 April 2019 Editor’s Draft of SVG Static.

Comments on this Editor’s Draft are welcome. Comments can be sent to www-svg@w3.org, the public email list for issues related to vector graphics on the Web. This list is archived and senders must agree to have their message publicly archived from their first posting. To subscribe send an email to www-svg-request@w3.org with the word subscribe in the subject line.

This document has been produced by the SVG Working Group as part of the Graphics Activity within the W3C Interaction Domain. The goals of the W3C SVG Working Group are discussed in the W3C SVG Charter. The W3C SVG Working Group maintains a public Web page, http://www.w3.org/Graphics/SVG/, that contains further background information. The authors of this document are the SVG Working Group participants.

This document was produced by a group operating under the W3C Patent Policy. W3C maintains a public list of any patent disclosures made in connection with the deliverables of each group; these pages also includes instructions for disclosing a patent. An individual who has actual knowledge of a patent which the individual believes contains Essential Claim(s) must disclose the information in accordance with section 6 of the W3C Patent Policy.

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.

1. Introduction

This section is non-normative

SVG Static is a profile of SVG designed with the requirements of static apps. The environment static apps run in is different than the environment of Web browsers in a few fundamental ways:

  1. Security: Web content is usually sandboxed, and has only a fraction of the capabilities that a static app has. One of the reasons for this sandboxing is to mitigate security risks that SVG content may contain. However, static apps are usually either not sandboxed or have a more permissive sandbox than Web content. Therefore, code that runs in a static app must be held to a higher standard of security.

  2. Performance: Web content is usually run in a separate process, which means the performace of that process has only an indirect affect on the performance of the entire app. If this separate process stalls, the entire app can continue and gracefully degrade behavior. However, static code runs in the app’s process, which requires more stringent performance targets.

SVG Static aims to adhere to the static app environment by meeting the above requirements.

SVG Static also has one additional goal:

  1. Ubiquity: SVG Static should be implementable as a system component on any modern computing environment. This means it should be small, lightweight, and only have few dependencies. The dependencies it does have should be standard components that already exist in most computing environments.

To meet these goals, SVG Static is a subset of SVG 1.1, which removes animation, interactivity, linking, remote resource loading, scripting, and CSS (among others).

1.1. Use Cases

This section is non-normative

SVG Static is designed to fit a number of use cases.

  1. Icons: Icons are often small vector graphics containing few graphical elements.

  2. Emoji: Emoji are often represented as small vector graphics.

  3. Color Fonts: Each glyph in a font is represented as a series of vector contours. Color fonts allow the glyphs to include color, in addition to their contours.

  4. Drawings and sketches: Drawings and sketches may be created with vector artwork tools. Depending on the complexity of the artwork, representing it using a series of vector drawing elements may result in a smaller file size than a raster format such as [PNG]. Drawings and sketches often need to be viewed outside of the Web platform.

1.2. Basics

SVG Static is presented as a series of modifications of [SVG11]. These modifications are applied as differences from that specification.

Note: This spec will likely be rebased on [SVG2] in the near future.

If the engine encounters an element or attribute that is forbidden, not supported, or not included in this specification, that element or attribute must be disregarded.

SVG Static is a standalone file type, expected to be rendered with a dedicated-purpose renderer. Therefore, SVG Static content must not be present as part of a larger XML (or HTML) document. If it is present as part of a larger XML (or HTML) document, the content should be interpreted as SVG proper.

Note: This means that browsers encounting a SVG Static root element within the DOM must not interpret it as SVG Static, even if it has the baseAttribute attribute set to static. If a Web author desires to use SVG Static on the Web, the img element may be used instead. This matches other static image formats such as [PNG]. A Web browser should implement SVG Static by linking with the system’s SVG Static facilities. This matches the implementation of other static image formats.

The root element of an SVG Static document must have the baseAttribute attribute set to static and the version attribute set to 1.1.

The file extension for SVG Static is .svn. The UTI for SVG Static is public.svg.static. The MIME type for SVG Static is image/svgstatic+xml.

User agents may limit the reference depth of references to implementation-dependent maximas. However, this limit must be greater than or equal to 1 reference.

XSL Processing is forbidden.

XML Entities and CDATA sections may be present.

Is it worth mentioning the 'HTML dialect' of SVG?

2. Concepts

Chapter is unchanged.

3. Rendering Model

Chapter is unchanged.

4. Basic Data Types and Interfaces

Chapter is unchanged.

Note: Because this specification removes some elements and attributes, not all of the syntax productions in this chapter are referenced by other sections of this specification. Therefore, not all of the productions in this chapter need to be implemented.

5. Document Structure

The root element must be an svg element, and all other svg elements are forbidden.

Section 5.8 "Conditional Processing" is deleted.

image elements must only contain base64-encoded data: URLs of [JPEG] or [PNG] images. [APNG] images must be rendered without animation, using standard backward-compatibility with static [PNG] images. All other image formats must be ignored.

All external resource loading is forbidden.

6. Styling

The style element and the style attribute are forbidden.

Using calc(), env(), or var() is forbidden.

Note: Other environments may relax these rules and allow these functions as necessary. For example, the [OPENTYPE] spec might allow env() or var() in color fonts to support font color palettes.

The CSS all property is forbidden.

All the global CSS keywords are forbidden. These include:

  1. initial

  2. inherit

  3. unset

  4. revert

7. Coordinate Systems, Transformations, and Units

Only the following units are supported:

8. Paths

The pathLength attribute on the path element is forbidden.

9. Basic Shapes

Chapter is unchanged.

10. Text

Entire chapter is deleted.

Note: This means that all text facilities are forbidden in SVG Static.

11. Painting: Filling, Stroking, and Marker Symbols

The display attribute is forbidden. Hiding elements can be achieved with the visibility attribute.

Delete section 11.6.2 The marker element.

The color-interpolation attribute is forbidden. All color interpolation occurs in the sRGB color space.

12. Color

Delete section 12.2: The color property.

Note: In some environments, the currentColor keyword is used to provide surrounding context to the SVG graphic. For example, in a color font glyph, currentColor may represent the text color of the surrounding line. Therefore, support of currentColor is required, but support of the color property to change currentColor is not supported.

Delete section 12.3: Color profile descriptions.

Note: This specification will likely adopt [SVG2]'s syntax for specifying colors outside of sRGB.

What should we do about non-sRGB color spaces?

13. Gradients and Patterns

The following attributes are forbidden:

Delete section 13.3: Patterns.

14. Clipping, Masking, and Compositing

Delete section 14.4: Masking.

The following attributes are forbidden:

The scroll value on the overflow property behaves identically to hidden.

The clip-path attribute must not be present on a clipPath element.

Every clipPath element must have either exactly zero or exactly one child.

The scroll and the auto values of the overflow property are forbidden.

15. Filter Effects

Entire chapter is deleted.

Note: This means that all filter facilities are forbidden in SVG Static.

16. Interactivity

Entire chapter is deleted.

Note: This means that all interactivity facilities are forbidden in SVG Static.

17. Linking

All external resource loading is forbidden.

Delete section 17.2: Links out of SVG content: the a element.

Delete section 17.3.3: Predefined views: the view element.

18. Scripting

Entire chapter is deleted.

Note: This means that all scripting facilities are forbidden in SVG Static.

19. Animation

Entire chapter is deleted.

Note: This means that all animation facilities are forbidden in SVG Static.

20. Fonts

Entire chapter is deleted.

Note: This means that all font facilities are forbidden in SVG Static.

21. Metadata

Entire chapter is deleted.

Note: This means that all metadata facilities are forbidden in SVG Static. Because the engine must ignore document constructs that aren’t included in this specification, it means metadata is ignored. This may be what the author intends.

22. Backwards Compatibility

Entire chapter is deleted.

23. Extensibility

Delete section 23.3: The foreignObject element.

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:

This is an example of an informative example.

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.

Advisements are normative sections styled to evoke special attention and are set apart from other normative text with <strong class="advisement">, like this: UAs MUST provide an accessible alternative.

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.

Implementations of Unstable and Proprietary Features

To avoid clashes with future stable CSS features, the CSSWG recommends following best practices for the implementation of unstable features and proprietary extensions to CSS.

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.

Index

Terms defined by reference

References

Normative References

[APNG]
S. Parmenter; V. Vukicevic; A. Smith. APNG Specification. URL: https://wiki.mozilla.org/APNG_Specification
[CSS-CASCADE-4]
Elika Etemad; Tab Atkins Jr.. CSS Cascading and Inheritance Level 4. 28 August 2018. CR. URL: https://www.w3.org/TR/css-cascade-4/
[CSS-COLOR-4]
Tab Atkins Jr.; Chris Lilley. CSS Color Module Level 4. 5 March 2019. WD. URL: https://www.w3.org/TR/css-color-4/
[CSS-DISPLAY-3]
Tab Atkins Jr.; Elika Etemad. CSS Display Module Level 3. 28 August 2018. CR. URL: https://www.w3.org/TR/css-display-3/
[CSS-ENV-1]
CSS Environment Variables Module Level 1 URL: https://drafts.csswg.org/css-env-1/
[CSS-MASKING-1]
Dirk Schulze; Brian Birtles; Tab Atkins Jr.. CSS Masking Module Level 1. 26 August 2014. CR. URL: https://www.w3.org/TR/css-masking-1/
[CSS-OVERFLOW-3]
David Baron; Elika Etemad; Florian Rivoal. CSS Overflow Module Level 3. 31 July 2018. WD. URL: https://www.w3.org/TR/css-overflow-3/
[CSS-SCROLL-SNAP-1]
Matt Rakow; et al. CSS Scroll Snap Module Level 1. 19 March 2019. CR. URL: https://www.w3.org/TR/css-scroll-snap-1/
[CSS-VALUES-4]
Tab Atkins Jr.; Elika Etemad. CSS Values and Units Module Level 4. 31 January 2019. WD. URL: https://www.w3.org/TR/css-values-4/
[CSS-VARIABLES-1]
Tab Atkins Jr.. CSS Custom Properties for Cascading Variables Module Level 1. 3 December 2015. CR. URL: https://www.w3.org/TR/css-variables-1/
[CSS2]
Bert Bos; et al. Cascading Style Sheets Level 2 Revision 1 (CSS 2.1) Specification. 7 June 2011. REC. URL: https://www.w3.org/TR/CSS2/
[JPEG]
Eric Hamilton. JPEG File Interchange Format. September 1992. URL: https://www.w3.org/Graphics/JPEG/jfif3.pdf
[OPENTYPE]
OpenType specification. URL: http://www.microsoft.com/typography/otspec/default.htm
[PNG]
Tom Lane. Portable Network Graphics (PNG) Specification (Second Edition). 10 November 2003. REC. URL: https://www.w3.org/TR/PNG/
[RFC2119]
S. Bradner. Key words for use in RFCs to Indicate Requirement Levels. March 1997. Best Current Practice. URL: https://tools.ietf.org/html/rfc2119
[SVG11]
Erik Dahlström; et al. Scalable Vector Graphics (SVG) 1.1 (Second Edition). 16 August 2011. REC. URL: https://www.w3.org/TR/SVG11/
[SVG2]
Amelia Bellamy-Royds; et al. Scalable Vector Graphics (SVG) 2. 4 October 2018. CR. URL: https://www.w3.org/TR/SVG2/

Informative References

[HTML]
Anne van Kesteren; et al. HTML Standard. Living Standard. URL: https://html.spec.whatwg.org/multipage/

Issues Index

Is it worth mentioning the 'HTML dialect' of SVG? ↵
What should we do about non-sRGB color spaces? ↵