SVG/Animation

From W3C Wiki
< SVG

There are several ways to animate SVG images:

  • Declarative:
    • SMIL syntax
    • CSS syntax
  • JavaScript DOM manipulation

SVG animation may include changing styles, geometry, transforms, or even frame-based animation through hiding and showing sections of the SVG document.

History

SVG 1.0 defined a set of animation elements that allowed authors to declaratively animate graphical elements. These animation elements were mostly derived from an extended subset of the Synchronized Media Integration Language (SMIL) specification, which also included a full animation model for audio, video, and other media operations via an markup/XML syntax; thus, SVG's original declarative animation features are referred to as SMIL animation.

SMIL as a whole had only limited adoption in browsers or on the Web, and other methods for controlling media, mostly based on JavaScript APIs, were specified and adopted instead; of all the SMIL features, modern browsers support only the SVG SMIL animation elements, and only some browsers do that. Because of SMIL's relatively complex timing and interaction model, and citing a lack of authoring tools, some browsers were reluctant to include full support for SVG SMIL animation.

In 2007, WebKit introduced an alternative declarative animation syntax using CSS instead of markup elements, including CSS animation, transforms, and transitions; the animation and transform functionality substantially overlapped with SVG's SMIL animation functionality. CSS animation, in part because of the familiarity with CSS syntax by designers and developers, and because the dominance of Flash had begun to diminish (thus opening up the need for alternative animation mechanisms), were widely adopted by content creators and support spread to other browsers.

Microsoft's Internet Explorer was the last of the major modern browsers to support SVG, beginning in IE9. While IE supports most features of SVG, they made an open decision not to support SMIL animation or SVG Fonts, citing overlap with other features; in the case of SMIL animation, they preferred the CSS animation syntax, and in the case of SVG Fonts, they preferred the new CSS WebFonts (WOFF) approach. Microsoft stated that they would not support SMIL animation unless there were a single unified animation model that was compatible with CSS animation, to decrease complexity of their implementation and of the Web platform.

Current Approach

SVG now has wide support in all modern browsers, including most mobile browsers. However, SVG 1.1 2nd Edition (the most recent Recommendation) is a relatively large and complex specification, and not all features are supported in all browsers, in addition to bugs and other non-interoperable behavior. This inconsistency creates a problem for content creators and authoring tools, because they can't depend upon the spec as a dependable indicator of features they can use; it's a problem for implementors (i.e. browsers) because they invest development and maintenance time on features that aren't used by authors.

In order to improve the consistence of SVG support overall, in order to make authoring easier for developers and designers, the SVG Working Group decided to simplify the SVG 2 specification, in a few ways:

  1. split out features that SVG now has in common with CSS (e.g. Transforms, Filter Effects, Masking, Compositing and Blending) into separate modules; these features started in SVG originally, but because CSS is more in demand since it can be applied to HTML as well as SVG, factoring features into CSS ends up improving the quality and performance of these features
  2. refer to features in HTML or CSS where possible, rather than creating alternatives (for example, reusing CSS text-wrapping rather than defining SVG-specific text-wrapping, or reusing HTML <video> and <audio> rather than duplicating the feature)
  3. remove any features that are not supported by the majority of implementations

In this light, developers from Mozilla and Google have created a new Web Animations specification, which defines a single unified animation model for animations done in CSS or element-based syntax, or in script. This specification is intended to be backwards-compatible with the most widely-supported and widely-used aspects of SMIL animation and CSS animation. Some of the more obscure aspects of SMIL animation may not be supported

This approach will allow authors to use any of these approaches, alone or in combination, and still have a single coherent, predictable animation timeline. For example, an author can create an animation using animation elements, combine it with a CSS animation, and change the behavior of both animations using JavaScript; this gives the most power and flexibility to authors, and can serve as the basis for script-based extension libraries.

It is expected that once Web Animations is finalized, all modern browsers will support this specification and all the related syntaxes (CSS, animation elements, and JavaScript).

Animation Elements

SMIL animation has been removed from SVG 2, and will not be added back. SMIL animation will still work in SVG 1.1 user agents.

However, there is still author desire for element-based syntax in SVG, and there is legacy content. To meet this requirement, the SVG WG has resolved to redefine SVG's SMIL subset in terms of the Web Animation model. Some features will change slightly, and some syntax has been simplified, but for the most part, older content will still be supported using this new syntax.

These element-based animation features are being defined in a separate SVG module, called the Animation Elements specification; this spec includes a full list of the [differences between https://svgwg.org/specs/animation-elements/#relationship-to-svg-1.1-animation Animation Elements and SVG SMIL Animation]. The editor for this specification is Brian Birtles from Mozilla, one of the editors of the main Web Animation spec.

The current draft contains some extensions to the SVG 1.1 SMIL-based animations, which are now possible using the new Web Animation model; however, the SVG WG has resolved to define a simplified version 1 which only includes features that match the current set of SVG SMIL animtation. This approach will allow all browsers to support the first version, and build on implementation experience and author demand for future features.

Because this new element-based animation syntax will not be defined in terms of the SMIL animation model, but rather the Web Animation model, authors should refer to this as element animation or Animation Elements, rather than SMIL animation. This will also help new authors learn this feature, without the confusion of referring to legacy specifications that are no longer supported.

Google has stated their intent to replace their native code implementation of SMIL animation in Chrome with a browser-hosted JavaScript implementation; this will not significantly effect the behavior of existing content.

Microsoft, the creator of the only major modern browser which does not support any element-based animation syntax, has not (as of March 2015) stated whether they will support Animation Elements; however, they have added support for CSS-based animation of SVG, and if a significant amount of content uses Animation Elements, they may decide to implement it since the amount of coding and maintenance will be minimal on top of the CSS animation support.

Animation Semantics

Some people have voiced the opinion that element-based animation syntax is more semantic than CSS-based animation syntax; this opinion is likely informed by the design principle of the separation of presentation and content, and by the fact that both the graphical elements and the animation elements are expressed in the same syntax (e.g. both use XML-like markup).

However, the consensus of the SVG Working Group does not share this opinion. While the SVG WG agrees that this is a reasonable and understandable association, neither the pragmatics nor the design philosophy of SVG support such a distinction, based on the following points.

SVG is presentational

SVG, as a rendering format, is inherently presentational, and does not typically distinguish between style and content.

For example, consider this markup showing a circle: 

<svg xmlns="http://www.w3.org/2000/svg">
  <style type="text/css">
    circle#orange-circle {
      fill: blue;
    }
  </style>   
  <circle id="orange-circle" cx="50" cy="40" r="20" fill="green" style="fill:red">
    <title>A yellow circle</title>
  </circle>
  <text>This is a purple rectangle</text>
</svg>

Despite several conflicting indicators, this circle will be rendered as red, because CSS style rules override presentational attributes, and the CSS cascade rules indicate that the greatest specificity (in this case, the style attribute declaration) overrides any other style rules. For all intents, and by any reasonable interpretation, this is a red circle. The cultural semantics vary from place to place (in Western cultures, red is strongly associated with danger or passion, while in Eastern cultures it symbolizes prosperity and good fortune), but how the color itself is applied to the circle is well-defined technically.

CSS is as integral to SVG as animation, and even predates the introduction of animation elements.

SVG has traditionally had a few types of elements and attributes, including shapes and geometry, presentational, grouping, linking, metadata, paint servers (e.g. gradients and patterns), and content sources (e.g. markers, clip-paths, masks, etc.). But none of them should be considered more “semantic“ than the other. Each can be changed via script or CSS.

SVG currently has relatively few semantic elements, i.e. elements that add intention and meaning to the content:

  • the <g> element adds structure and associates sibling elements together in a general way, in a tree structure
  • the <title> and <desc> elements add textual descriptions to a shape or group
  • the <a> element adds linking behavior to SVG content
  • the <metadata> element allows machine-readable content to be included
  • ?

Future general semantic elements or attributes may be added to SVG, including:

  • a <connector> element to indicate a relationship between two shapes or groups of shapes
  • a “virtual grouping” mechanism to associate several shapes together in addition to the tree-structure grouping

Screenreaders don't distinguish

Currently, few screenreaders interpret SVG at all.

To the extent that screenreaders do understand SVG, only the following factors are relevant:

  • document order
  • grouping (only sometimes)
  • text content (i.e. the content of the rendered <text>, <tspan>, and <textpath> elements
  • metadata (or meta-textual) content (i.e. the content of the <title> and <desc> elements

Screenreaders should respect the value of the CSS display property, and should not read content that is display:none'.

No known screenreader (except informal experimental prototypes) interprets the geometric or styled presentation of an SVG document.

No known screenreader interprets animations, nor is the SVG WG aware of any intent or interest to do so. The underlying OS-level accessibility APIs do not support any concept of animation, other than update notifications such as via aria-live', which is purely textual.

Thus, claims that SMIL animation (or Animation Elements) are more accessible are purely theoretical at best.

In fact, modern screenreaders increasingly understand and deal with both CSS and JavaScript, and so any future animation support in screenreaders would just as readily support CSS animations as animation elements.

It is true that declarative animation, which includes both CSS animations and animation elements, does afford exposing authorial intent better than scripted animation; so declarative animation does have advantages for any future support in screenreaders and authoring tool interchange.

But it is not the case that animation elements are or are likely to ever be more accessible than CSS animations.

All animations follow the same model

Because the underlying animation model for animation elements, CSS animations, and scripted animations will be the same in upcoming versions of modern browsers, there is no meaningful distinction between any of these specific types of animation in terms of how they affect the SVG document.

Any future browser, authoring tool, or screenreader should operate on the underlying data model, not the syntactic expression of that animation.

Add semantics to SVG

SVG may be considered as a “host language” for semantics. By using ARIA, RDFa, data-* attributes, or other mechanisms, you can add machine-readable semantics to SVG. These semantics can be conveyed to humans by these software user agents.

Such a wide variety of concepts can be presented graphically through SVG that it would have been a mistake to add inherent specialized semantics to the language itself. An SVG can be an icon, a line-drawing of a physical object, a data visualization, a standardized symbol such as an electronic component or map legend, a GUI object such as a menu, a game character, a pattern, or simply abstract art. None of these should have inherent precedence over the other, and each can have its own specialized vocabulary that can be added to SVG through its semantic extension points.

Animation Security

Declarative animation, in principle, is more secure than scripted animation.

JavaScript is a powerful, fully-expressive programming language with many possible security concerns; so, many environments don't wish to expose those risks by allowing JavaScript to execute, since it might be doing other things than simple animation.

This means that these environments, such as social media, don't want to allow content to be loaded via the <object>, <iframe>, or <embed> elements. Thus, SVG content can only securely be loaded in HTML via the <img> element.

Currently, loading an SVG document via the <image> element prevents script from executing, and prevents external resources from being loaded, to prevent fingerprinting and other security attacks. Browsers which currently support declarative animation also support running timeline-based animations in SVG referenced in the <img> element.

From a spec perspective, the SVG Integration specification defines the animated image document and secure animated mode, which define that inline declarative animation should work for SVG content referenced by an HTML <img> element. This satisfies the use case for referencing secure animated SVGs from HTML.

Mozilla cites a potential keylogging threat as a concern for not supporting interactive declarative animation execution in <img> content; however, in reality, this threat would be neutralized by by another features of secure animated mode: it does not allow external resources (hence, no outbound links, either). If external resources are not loaded, there are no known security or privacy threats from declarative animation in SVG (either with CSS or element animation).

Retrieved from "https://www.w3.org/wiki/index.php?title=SVG/Animation&oldid=83073"