SVG Native

Editor’s Draft,

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

Abstract

SVG Native is a profile of SVG 1.1 designed for interoperability with native 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 4 December 2019 Editor’s Draft of SVG Native.

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 Native is a profile of SVG designed with the requirements of native apps. The environment native 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 native app has. One of the reasons for this sandboxing is to mitigate security risks that SVG content may contain. However, native apps are usually either not sandboxed or have a more permissive sandbox than Web content. Therefore, code that runs in a native 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, native code runs in the app’s process, which requires more stringent performance targets.

SVG Native aims to adhere to the native app environment by meeting the above requirements.

SVG Native also has one additional goal:

  1. Ubiquity: SVG Native 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 Native 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 Native 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 Native is presented as a series of modifications of the Secure Static Mode of [SVG2]. These modifications are applied as differences from that specification. Rather than being a strict line-by-line diff, this specification describes the differences directly.

If functionality present in [SVG2] isn’t present in the SVG Native specification, SVG Native includes that functionality.

There are numerous differences between the SVG Native format and the [SVG2] format. Currently, all differences are reductive; all functionality in SVG Native is also present in [SVG2]. A conforming SVG Native document must only include functionality present in the SVG Native format. A conforming SVG Native renderer should ignore any functionality requested by a document that is not present in the SVG Native format. If a SVG Native renderer intentionally chooses to honor functionality beyond the SVG Native specification, it must do so in accordance with the [SVG2] specification. There are a few exceptions to this throughout this specification below, where an SVG Native renderer must not include some functionality from [SVG2].

Note: If a document uses parts of SVG that aren’t part of SVG Native, then it isn’t a conformant SVG Native document. When an SVG Native renderer opens such a file, it should ignore all of those parts. Therefore, all SVG Native renderers should produce the same rendering for the same document. However, there may be renderers which intentionally decide to honor parts of SVG that aren’t part of SVG Native. In order to make it more likely that a given document’s rendering is predictable, even in these renderers, SVG Native authoring tools are recommended to always emit documents that conform to this specification. The SVG Working Group is considering producing a validator to determine whether a given document is conformant to the SVG Native format.

The file type and mime type is being discussed in this GitHub issue.

SVG Native is a standalone file type, expected to be rendered with a dedicated-purpose renderer. Therefore, SVG Native 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 Native root element within the DOM must not interpret it as SVG Native, even if it has the baseAttribute attribute set to native. If a Web author desires to use SVG Native on the Web, the img element may be used instead. This matches other native image formats such as [PNG]. A Web browser should implement SVG Native by linking with the system’s SVG Native facilities. This matches the implementation of other native image formats.

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

The file extension for SVG Native is .svn. The UTI for SVG Native is public.svg.native. The MIME type for SVG Native is image/svgnative+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 not supported by SVG Native.

No namespaces other than xlink are supported inside an SVG Native document. From the xlink namespace, only href is supported.

A valid SVG Native document must not contain any of the external or internal XML DTD subset.

1.3. Common Attributes

SVG 2.0 defines sets of common attributes wich might apply to multiple elements. These sets of attributes are not supported by SVG Native:

1.4. SVG Modules

SVG Native is a subset of the content in the [SVG2] specification, and some associated modules. They are:

No other SVG modules are supported by SVG Native. This includes:

2. Rendering Model

SVG Native does not support masking.

The following attributes are not supported by SVG Native:

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

The clip-path attribute is not supported on a clipPath element.

Every clipPath element must have either exactly zero or exactly one child. Anything more than that is not supported by SVG Native.

The scroll and the auto values of the overflow property are not supported by SVG Native.

3. Document Structure

The root element must be an svg element, and all other svg elements are not supported by SVG Native.

Conditional processesing attributes and elements are not supported in SVG Native. These include the switch element.

The meta and metadata elements are not supported in SVG Native.

Elements in foreign namespaces are not supported in SVG Native. Attributes in foreign namespaces, except the xlink (http://www.w3.org/1999/xlink) namespace, are not supported in SVG Native.

Because SVG Native is a subset of [SVG2]'s Secure Static mode, only image elements which contain base64-encoded data: URLs of [JPEG] or [PNG] images are supported. [APNG] images are be rendered without animation, using standard backward-compatibility with static [PNG] images. No other image format is supported by SVG Native.

All external resource loading is forbidden.

The symbol element is not supported by SVG Native.

4. Styling

The style element and the style attribute are not supported in SVG Native.

Note: Style properties can be set by presentation attributes, which must be parsed and processed according to the SVG and CSS specifications, other than the specific restrictions outlined in this section.

calc() is not supported by SVG Native.

env() and var() are supported by SVG Native.

Note: Because of the other restrictions on styling, there is no way to set new values to CSS custom properties inside an SVG Native document. However, some rendering environments (e.g., for SVG fonts) will expose custom property values from an external document, as if they were inherited by the root element of the SVG Native document; the `var()` function can therefore be used similar to the `env()` function, to access this value if it exists and set a fallback value if it doesn’t.

The CSS all property is not supported by SVG Native.

All the global CSS keywords are not supported by SVG Native. These include:

  1. initial

  2. inherit

  3. unset

  4. revert

Percentage length values are not supported by SVG Native.

Relative units are not supported by SVG Native.

5. Geometry Properties

Keyword values, such as auto, are not supported in the cx, cy, r, rx, ry, x, y, width, and height attributes.

Note: Raw numbers are supported by these attributes, in accordance with the [SVG2] rules on parsing presentation attributes.

6. Coordinate Systems, Transformations, and Units

Only the following units are supported by SVG Native:

The transform property is only supported by SVG Native on the following elements:

The viewBox attribute is only supported by SVG Native on the svg element.

The preserveAspectRatio attribute is only supported by SVG Native on the following elements:

7. Paths

The pathLength attribute on the path element is not supported by SVG Native.

8. Text

All text and fonts facilities are not supported by SVG Native. This includes text, tspan, textPath, font, glyph, missingGlyph, hkern, vkern, font-face, font-face-src, font-face-uri, font-face-format, font-face-name, inline-size, shape-inside, shape-subtract, shape-image-threshold, shape-margin, shape-padding, text-anchor, glyph-orientation-horizontal, glyph-orientation-vertical, kerning, text-overflow, 'xml:space', text-decoration-fill, text-decoration-stroke, letter-spacing, text-align, text-align-last, text-indent, word-spacing, white-space, vertical-align, dominant-baseline, alignment-baseline, baseline-shift, direction, text-orientation, writing-mode, font, font-family, font-feature-settings, font-kerning, font-size, font-size-adjust, font-stretch, font-style, font-variant, the subproperties of font-variant, font-weight, text-decoration, text-decoration-line, text-decoration-style, text-decoration-color, and text-rendering.

9. Embedded Content

HTML elements in SVG subtrees are not supported by SVG Native.

foreignObject is not supported by SVG Native.

10. Painting: Filling, Stroking, and Marker Symbols

The display attribute is not supported by SVG Native.

Note: Hiding elements can be achieved with the visibility attribute.

The marker element is not supported by SVG Native, nor are the marker, marker-start, marker-mid, and marker-end properties.

The context-fill and context-stroke values are not supported by SVG Native.

Note: Authors wishing to use a contextual color from the environment may use currentColor.

The color property is not supported by SVG Native.

Note: The absence of color makes it impossible to change the value of currentColor from its initial value.

The vector-effect, paint-order, color-interpolation, and will-change attributs are not supported by SVG Native.

All color interpolation occurs in the sRGB color space.

11. Gradients and Patterns

Only the userSpaceOnUse value of gradientUnits is supported. According to [SVG2], the default value of gradientUnits is objectBoundingBox, which isn’t supported. This means that all gradient elements must include gradientUnits="userSpaceOnUse" to be valid.

The pattern element is not supported by SVG Native.

12. Scripting and Interactivity

All scripting and interactivity facilities are not supported by SVG Native. This includes the pointer-events and zoomAndPan attributes and the script element. No contents of the SVG Native document are focusable.

13. Linking

All external resource loading is forbidden. All URLs must either be a data URL or only consist of a fragment identifier.

The a element and view elements are not supported by SVG Native.

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-DISPLAY-3]
Tab Atkins Jr.; Elika Etemad. CSS Display Module Level 3. 11 July 2019. 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-FONTS-3]
John Daggett; Myles Maxfield; Chris Lilley. CSS Fonts Module Level 3. 20 September 2018. REC. URL: https://www.w3.org/TR/css-fonts-3/
[CSS-FONTS-4]
John Daggett; Myles Maxfield; Chris Lilley. CSS Fonts Module Level 4. 13 November 2019. WD. URL: https://www.w3.org/TR/css-fonts-4/
[CSS-INLINE-3]
Dave Cramer; Elika Etemad; Steve Zilles. CSS Inline Layout Module Level 3. 8 August 2018. WD. URL: https://www.w3.org/TR/css-inline-3/
[CSS-LOGICAL-1]
Rossen Atanassov; Elika Etemad. CSS Logical Properties and Values Level 1. 27 August 2018. WD. URL: https://www.w3.org/TR/css-logical-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-OVERFLOW-4]
David Baron; Florian Rivoal. CSS Overflow Module Level 4. 13 June 2017. WD. URL: https://www.w3.org/TR/css-overflow-4/
[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-SHAPES-1]
Vincent Hardy; Rossen Atanassov; Alan Stearns. CSS Shapes Module Level 1. 20 March 2014. CR. URL: https://www.w3.org/TR/css-shapes-1/
[CSS-SHAPES-2]
CSS Shapes Module Level 2 URL: https://drafts.csswg.org/css-shapes-2/
[CSS-TEXT-3]
Elika Etemad; Koji Ishii; Florian Rivoal. CSS Text Module Level 3. 13 November 2019. WD. URL: https://www.w3.org/TR/css-text-3/
[CSS-TEXT-4]
Elika Etemad; et al. CSS Text Module Level 4. 13 November 2019. WD. URL: https://www.w3.org/TR/css-text-4/
[CSS-TEXT-DECOR-4]
Elika Etemad; Koji Ishii. CSS Text Decoration Module Level 4. 13 March 2018. WD. URL: https://www.w3.org/TR/css-text-decor-4/
[CSS-TRANSFORMS-1]
Simon Fraser; et al. CSS Transforms Module Level 1. 14 February 2019. CR. URL: https://www.w3.org/TR/css-transforms-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/
[CSS-WILL-CHANGE-1]
Tab Atkins Jr.. CSS Will Change Module Level 1. 3 December 2015. CR. URL: https://www.w3.org/TR/css-will-change-1/
[CSS-WRITING-MODES-3]
Elika Etemad; Koji Ishii. CSS Writing Modes Level 3. 24 October 2019. PR. URL: https://www.w3.org/TR/css-writing-modes-3/
[CSS-WRITING-MODES-4]
Elika Etemad; Koji Ishii. CSS Writing Modes Level 4. 30 July 2019. CR. URL: https://www.w3.org/TR/css-writing-modes-4/
[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/
[HTML]
Anne van Kesteren; et al. HTML Standard. Living Standard. URL: https://html.spec.whatwg.org/multipage/
[JPEG]
Eric Hamilton. JPEG File Interchange Format. September 1992. URL: https://www.w3.org/Graphics/JPEG/jfif3.pdf
[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

[CSS-COLOR-4]
Tab Atkins Jr.; Chris Lilley. CSS Color Module Level 4. 5 November 2019. WD. URL: https://www.w3.org/TR/css-color-4/

Issues Index

The file type and mime type is being discussed in this GitHub issue.