Why is the SVG Animate Element disallowed?

7 posts / 0 new
Last post

The epub3 spec states

"The [SVG] Animation Elements and Animation event attributes must not occur."


but the spec doesn't elaborate why this is so. Can anyone explain why these elements are disallowed from the spec?


In a nutshell: lack of support.

I exect they'll be supported in the future, as the question comes up each revision. For example, see this issue for 3.0.1:


To date there has been hesitancy to allow, however, as it would further fragment cross-reading system compatibility of content. Lack of consistent HTML5 support is painful enough for content creators to work around.

Well, the 'support' of basic declarative animation in SVG is much better for the usual suspects
(Presto, Gecko, WebKit, Blink, Batik) than for some other features of SVG or HTML5 or EPUB allowed in EPUB, for example SVG fonts, own color profiles are quite problematic or selection of different styling, required audio and video formats, which are not necessarily license free for implementors.
Therefore animation with SVG seems to be not a big problem compared to those other issues,
if authors rely at all on EPUB statements, what is required to be supported. Even more, XHTML and SVG have build in accessibility features, therefore for authors it is not a big problem to provide a static or text alternative for animated SVG in case a viewer does not manage the animation. To select this feature for exclusion seems to be an arbitrary choice, which forces authors to extent the EPUB 3 format itself, what is not very useful, if they suddenly start to provide their own version '3.dynamic' or something like this ;o)

I tried some animation and animationcolor SVG in EPUB3 we are building, and they works fine on Adobe Digital Edition 4, Ibooks, and Gitden Reader. So, it seems the mayor EPUB3 reader in MacOs, iOs, Android and Windows has support for SVG animation.

'works fine' is maybe slightly exaggerated, but it works better than or comparable to some other SVG features, currently already allowed in EPUB.
And the interpretation is typically much better than for several features of EPUB 3, not related to other recommendations ;o)

Concerning animateColor - this was ok in the past, but for example Mozilla/Gecko developers do not like it and refuse to implement it, therefore it is already marked as depreciated. On the other hand, several viewers have some problems in detail to get it right in general for the element animate. Because the most advanced EPUB viewers I have seen up to now are using Mozilla/Gecko, it is at least no good idea for authors to rely on animateColor, if there are not many authors/users forcing Mozilla/Gecko to implement it :-(
I think, Microsoft does not like declarative animation at all, maybe they do not like standards anyway, therefore not sure, if they matter here, because usually they do it somehow different, not convenient for authors or users.

How good declarative animation works in detail with the usual suspects, see:

One cannot say, if works fine, but because authors can provide several alternatives in SVG, current faults of viewers are nevertheless not a big problem for authors, at least not for simple animation structures.

A remaining problem can be devices with small computing power and color management, those devices appear to be still in use for EPUB presentation. But the color problem applies as well for static SVGs and raster images and the computing power problem applies as well for video and maybe even more, if one starts to simulate animation with scripting. For scripting
authors have to provide alternatives anyway, therefore it should be sufficient to require text alternatives for animation as well.

Well, actually all the mayor EPUB3 reader support SVG animate better than most standard EPUB3 features... Ibooks, Adobe Digital Edition 4, Gitden reader, Azardi... I'm not talking about some minor EPUB3 reader. And: why use javascript for anything when exist a declarative way to do it? I think SVG animation is more consistent with the EPUB3 accessibility policy too: it can work turning off javascript.

javascript cannot be used as replacement for declarative animation as well, because javascript
is only for decoration, not for relevant content. The requirement for EPUB3 is anyway, that the
content is accessible completely with and without activated script interpretation.
Therefore javascript cannot be used to work around restrictions for EPUB3.
The replacements for animations are currently typically static graphics, text and video - graphics and video will typically require a text alternative as well to be accessible, especially video in EPUB3 has the practical problem, that the required format will not be interpreted by all viewers due to licensing problems - clearly a bug in the requirements of EPUB3 to require, what cannot be done by all user-agents for legal reasons (to require video and audio formats for HTML5 or SVG failed already for the same reason).
Obviously declarative animation in SVG would be an accessible alternative for several use cases, if combined with meaningful title and desc elements.
However, to do this correctly, this requires an author defined extension of EPUB3 - one would have to change the version indication to do this ;o)
This should be not really a problem, because already version 3.0.1 is borked by having no own version indication ;o) Someone just has to define a version, that allows declarative animation.
Once I really want it into one of my books, maybe I will define such an extended version ;o)

The question for me about capabilities of EPUB book readers/viewers is, which rendering engine do they use, the same as the usual browsers or own? Only for a few I know this, the capabilities of others are completely opaque, especially if one cannot get them for free or if they
do not run on Linux, therefore I assume they are not of practical importance, if they do not manage to be omnipresent and using an own renderer and not just a renderer available for everyone to test.

Secondary menu