deutsche Version
Project Start: 2005-08
Current State: 2018-08
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 available 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.
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.
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
distinguish 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 independent 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 edition 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)
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.
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:
Indicator | Meaning | Explanation |
---|---|---|
P | Precision test | With this it is possible to see precisely, if an animation is correct. |
Q | Qualitative test | It is not expected, that testers are able to test the animation very precisely, the question is more: Does it animate somehow? |
U | edUcational, entertainment test | The 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. |
A | Application | Examples of this type are similar to the U type, maybe this can lead to an application or can already be used as an application. |
F | Failure, error handling | Tests 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. |
X | eXperimental | Mainly 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. |
S | Specification | These 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. |
I | Interaction | Example 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 1 | This 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 2 | Similar 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 3 | This 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. |