Examples and Tests for SVG Animation

deutsche Version
Project Start: 2005-08
Current State: 2013-10

Author

Dr. Olaf Hoffmann
Appelstraße 2
30167 Hannover
Deutschland/
Germany
German web-page

Abstract

A systematic test ensemble for declarative animation with SVG Tiny 1.1, SVG 1.1 and SVG Tiny 1.2 is presented including more than 1400 examples for all animatable attributes and properties and samples for all animation elements and attributes.
Test results are avialable for the following user agents: Amaya, KSVG, the Adobe plugin, Renesis-player, Squiggle/Batik, Opera, several variants of WebKit (Safari, Google Chrome, Chromium, QT4-Variante, GTK-Variante), Mozilla Gecko, microsoft internet-explorer. The test results are discussed including an estimate for the probability for a correct display of a random choice animation example.
A significant improvement of user agents is necessary, that authors can concentrate on their work and not on the abilities of user agents.

Index

Introduction

SVG is a standardised format offering a simple possibility to create animations without special tools. As with (X)HTML only a simple text editor is necessary for SVG, but other programs are not excluded. Similar important is, that declarative animation is a descriptive method, the elements have a defined and understandable meaning, SVG describes what should happen, but does not determine, how to reach this. This is the task for the user agent, not for the author of the document.
As a consequence of digitalisation we have a certain loss of continuity - with declarative animation this is not the case, a continuous animation stays continuous in the document and it is not important, how the document will be displayed. At the moment this is in a manner of speaking always a sequence of single images, but should there be no techniques in the future, to display continuous course of events with a continuous animation? A classical oscilloscope is able to do this already today. And SVG is a format, the author can use to formulate, what should be displayed continuously.
At the same time this format is qualified for internet applications. These conditions were limited for previous other formats like GIF animations or macromedia flash. Declarative SVG animations are completely accessible like (X)HTML for authors and users.

Using SVG I observed, many user agents have especially problems with the declarative animation of several SVG attributes. Sometimes it is not easy to get an example for the animation of a not so widely used attribute to test an user agent or just to realise the animation. The official test suites for SVG just offer a small number of examples for just a few attributes.
So I decided to offer some very simple examples or samples for the animation of all attributes included in SVG tiny and well separated additional samples for SVG 1.1, which are not part of SVG tiny.

The chapters here will be correlated to the chapters of the SVG specification by the titles, not by numbering, because for animation it is easier to start for users with simple examples for basic shapes, assuming SVG is interpreted almost correct without animation.

Status of the Project

I started 2005-08 to write. Systematic samples are almost complete since the end of 2005-12. From time to time a few example are added, refined or corrected.
Work in progress is to offer more quantitative tests. Either it should be possible to see directly, if a user agent is wrong or just by comparing with the short description, not by looking in the source code. In 2005 the following question was mainly in the focus: Does it animate? Current work will concentrate more on the questions: How accurate is the animation? Which example is useful to destinguish immediately between correct and incorrect behaviour without looking for details in the source code? This should improve these tests in the direction of higher accuracy and quality both for the test cases and the user agents.

What about SVG tiny 1.2? Some parts of SVG tiny 1.1 are skipped, some new features are added or taken from basic, some others are changed, due to changes in SMIL or directly in the SVG tiny specification. Tests are provided as complements to the SVG 1.1 tests, not as a completely indenpendent set.

Note, that typically the tests are older than the second edition of SVG 1.1 (2011-08-16), therefore if not mentioned otherwise and if there are backwards incompatible changes in the second edition, they test only the first edition - I will care about this problem. To test the first edition however is still useful, because many viewer versions are published before the second edtion as well.

And please - if you discover an error or a misinterpretation in the documents, report it to me immediately. Even if you are not sure, I will think about the problem. Meanwhile I discovered several errors myself and fixed them, but often it is not so easy to look for errors in one's own documents.
As already well known from teaching at university, preparing a new lecture the lecturer learns more than the students ;o)

Navigation, Style and Accessibility

If the user agent provides a site navigation bar (conform interpretation of the link element in HTML2, HTML3.2, HTML4.01, XHTML1.0, XHTML1.1, XHTML+RDFa1.0), this can be used for navigation in this project. If not, links to chapters, sections and subsections can be found in the index above. Chapters and index are available with the small navigation box on each page.
If the user agent supports CSS: Beside the default bright 'Minimal Style' with alternate style it is accessible 'Dark Style' and 'No Style' for your convenience, too. Just have a look in the style navigation of your user agent. If the user agent does not support XHTML or the XML-stylesheet processing instruction, the CSS is without any meaning.

Tests

Systematic tests are mainly done with available user agents on Debian Linux (firt on version 3, later on 5 and 6, the currently stable version).

Additionally the samples are checked with the validator of W3C - this means, that the examples passed the validator, it is a check of the documents, not of the validator. Anyway, maybe the validator does not check all values of attributes. Therefore this is no guarantee for correct values and with this check it is not guaranteed that the descriptions of the samples are correct.

Vendors of other currently not tested user agents may want to have their product tested here, too. I can do this, if a Debian (stable) package is provided, an easy to install static tar.gz (compressed archive) may work, too. Since 2009-01 windows vista is available too.

Test results are marked with 'ok' or 'fail'. With 'fail' the background colour is changed (only CSS)- red means 'completely wrong or ignored', orange means 'parts can be correct' and yellow indicates, that there are minor errors, not the focus of the test. Often, if the result is 'fail' there will be a short comment on the wrong behaviour. Anyway for details the users have to look in the source code of the sample to evaluate the behaviour themselves.
A summary of the test is provided in the chapter 'Test Results and Display Probability'.
Currently all tests neglect possible progressive rendering. Effects from progressive rendering at the beginning of a document are not indications for a failed test, they can be neglected for such tests.

The tests are marked with additional indicators. They can be used, to identify which kind to test can be expected. The overall indicator starts with § followed by single indicators. The order is important, it starts with the most important indicator for testing.
An example is: §M(1)PU
The following table explains the meaning of the indicators:

Meaning of test case indicators
IndicatorMeaningExplanation
PPrecision testWith this it is possible to see precisely, if an animation is correct.
QQualitative testIt is not expected, that testers are able to test the animation very pecisely, the question is more: Does it animate somehow?
UedUcational, entertainment testThe focus of this example is to see, if something works in a more complicate example, maybe useful to learn something about SVG animation or about the theme of the example itself.
AApplicationExamples of this type are similar to the U type, maybe this can lead to an application or can already be used as an application.
FFailure, error handlingTests of this type are not intended as useful samples, they mainly test error handling for erratic documents, if this is different from providing an error message.
XeXperimentalMainly these examples focus on some unclear parts (for me) of the specification, I am not sure, if these tests are really relevant for SVG. If somebody knows more, please send me an email.
SSpecificationThese examples care about inconsistencies and errors in the specifications. Sometimes the errors can be solved to get a correct behaviour anyway, sometimes just some indications are given, what are the problems and which behaviour is inconsistent.
IInteractionExample with interaction, don't wait, do something explained in the text. Interactive elements are often marked with a blue stroke.
M(1)lazy, tired tester Model 1This is designed especially for fast tests. Colours and behaviour are always the same - the animated object is blue, trajectories and help objects are in gray and if something red appears, the test fails.
M(2)lazy, tired tester Model 2Similar to M(1), but the indication with red for fail is not or just in parts possible. For colour animations the same visible effect can be realised for stroke with simpler methods than for fill, there has to be no difference between stroke and fill.
M(3)lazy, tired tester Model 3This is a model for correlated animation. The independent element is dark blue, the dependent is light blue. The colours are gray, if an element is not in its active duration of animation. For colour animations fill is tested for correlation and stroke has the same visible effect without correlation.