Re: SVG animations without SMIL

Tab Atkins Jr. :
...
>There is no distinction between "content" and "style" animations.
>They are identical.  SMIL has a few facilities that CSS animations
>don't, and vice versa, but that's not due to "content" vs "style".
>There is no meaningful semantic difference between the two categories;
>machines treat them the same.  (Semantics being the way we communicate
>our intent to machines, so they can use the page better; we
>communicate our meaning to humans with style and presentation.)
...

Obviously you missed the point, why CSS was invented at all,
it stopped the obfucation of content with styling issues and 
we got HTML4 and XHTML (and SVG, XML etc) for content and the 
separation of styling to CSS (and java-script), you can have 
alternative styles for the same content but none of them changes 
the meaning of content.
The default presentation is without styling alternatives by the author.

With SMIL animation indeed you can have both, either
animating the content or the presentation, or if it does
not matter, respectively it the animation has priority over
styling, you can animate both as well on top of all.
SMIL itself even has timesheets to provide alternative views
for different groups of the audiences with different
capabilities to understand content.
Would be a nice improvement to allow and implement
timesheets for SVG to get a generic access to
alternative animated views by selecting between 
alternative XML stylesheet processing instructions.

If there is some CSS animation noted within a stylesheet,
it is of no relevance for the meaning of the content, the
stylesheet is applied to.
Due to my experience, CSS styling in general is a rare use 
case for (animated) SVG documents.
In practice most authors of SVG documents do not apply
stylesheets at all to their documents to provide alternative
presentations for them, therefore the usage of CSS for
SVG is very limited, but still ok and available - at least
I use it to provide alternative styles for some documents,
unfortunately some viewers do not allow the audience to
select between alternatives, none indicates actively, that there
are alternative available, maybe another reason, why
most authors do not provide stylesheets at all for their 
SVG documents, or as you note:

>If you can't in practice use something because it won't be available 
>to ~1/3 of your users, and there's no realistic path to making that fraction
>much smaller, it's something to deprecate and discourage, not continue
>pretending it's a useful standard.

According to this, CSS styling of SVG should be deprected and discouraged.
But I think, this conclusion is wrong as well, because it provides only
alternative views on the content. If users of micrososft internet explorer or
WebKit have no access to the alternative views, it is not a big problem,
because they still have the default presentation. If there is a hint given by 
the author, they can switch to another viewer with such capabilities.
Therefore it has some use, if authors provide (alternative) stylesheets
for their documents, even if they are not accessible to the majority of the
audience. Often these stylesheets care about problems of minorities with
the requirement of an alternative access, typically those minorities 
already know, that some viewers have almost no accessibility helps
and are therefore quite useless for them.
Concerning CSS animation, maybe one could provide specific alternatives
for people with reduced capabilities to follow fast changes, but 
unfortunately CSS animation has no event management as declarative
animation in SVG has (and for example mozilla/gecko does not support 
anymore without scripting), therefore not reasonable, that authors 
will use it at all to provide an alternative CSS animation view for an
animated SVG document.
This is still a long way for CSS animation to cover the use case to
provide alternatives for minorities with specific problems.

But concering declarative animation in SVG, if the interpretation by the 
viewer is missing, often the static view on the document is misleading, 
the animation is relevant to understand the content.
Feature switches are disliked by some vendors either, therefore nothing for
authors as well to provide alternatives.
The remaining alternative is only text in the title and desc of the root 
element of the document - not sure, if this is considered to be enough for
users of micrososft internet explorer or WebKit, especially because these
viewers have no other access to this alternative than looking into the
source code of the document.
I even checked in these days some alternative XSLT stylesheets to
expose the text alternative as (X)HTML to users on demand, but even
this does not work properly in several common viewers.

Therefore there is not much hope for the audience to get a comfortable
alternative by current viewers for animated SVG documents,
CSS or XSLT alternatives are not selectable,
feature switching does not work in all viewers or will be maybe removed as 
well in the near future.
If we put all this together, the audience can only guess, that there is 
something wrong with the presentation/ the viewer, if declarative
animation is not supported.
Typically authors cannot provide detailed indications, that the presentation
of an SVG file is correct.
Incomplete implementations will be always surprising and frustrating for the
audience. Authors cannot change this, implementors can.


Olaf

Received on Saturday, 6 June 2015 13:46:54 UTC