Re: clarification on "declarative animation value conservation and use" requirement request

Cameron McCormack:
> Hi Olaf.
>
> Yesterday at the SVG WG meeting we discussed your request for SVG2 that
> you describe in:
>
>    http://lists.w3.org/Archives/Public/www-svg/2010Nov/0015.html
>
> We resolved not to require support for this functionality, since we were
> unable to determine what use cases it would support.  If you could reply
> with some examples of where you would want to use this declarative
> storing and re-fetching of animated values, we will discuss the topic
> again.
>
> Thanks,
>
> Cameron
> (ACTION-3199)

There are different use cases, but I think, all are mainly related
to declarative user interactivity.

As we already know, to-animations are typically wrong or incomplete
implemented. And I have the impression, that neither implementors
nor the SVG-WG will manage to get it right at all, as intended by SMIL.
Such a feature could be a more stable alternative for
authors to create smooth changes from the current values to a
given value - or more in general from a conserved value to a new
value. This can result in an advanced technique similar to 
the proposal for CSS-transitions with the advantage of declarative
animation in SVG - precisely defined timing and events.
This means, authors could really use this, if they need predictable
declarative behaviour and not just decoration as intended by the
vague CSS-transition proposal.
Maybe one has to ask the CSS-WG if they have use cases
for transitions - well, if they have not, this should be dropped
as well ;o) At least to get nice looking interactive transitions
effects I already tried to use to-animations. Due to implementation
problems for to-animations in general and especially to animateTransform,
practically this is not usable currently as intended. Such a feature
could stabilise such wrong implementations.
As defined by SMIL (and not correctly implemented in typical
current viewers), clever combined to-animations have the potential to 
conserve approximately some animation values, but this method is
not general and simple enough for typical authors and applications.

The feature can be used as well in simple declarative games and in
applications, that can help users as a kind of more complex measure
to compare sizes and shapes in technical or scientific 
drawings/applications, if they are able to conserve different stages 
of an animated entity with each other or with other conserved entities
declaratively.
For example as you can use stroke-dasharray as a measure for
the length of curved paths, one can use conserved values of
animations to compare and to measure a lot of things, if some
animations are clever combined and interactively used.

I think, in the minutes, this was discussed, it was mentioned,
that one can do similar things with scripting. But there is no
scripting language required to be interpreted and as an author
one has to take into account, that users may have switched the
interpretation of scripts off (as I typically do) - therefore even if
one offers this with scripting, one still needs a reliable 
declarative fallback to provide a similar, really working alternative
for serious applications.

Finally it is yet another attempt to increase the usability of SVG
for wider user groups, similar to other rejected proposals ...
And indeed, it can be ok as well to restrict the usability of SVG
instead or to focus on what is currently already possible with
faulty existing implementations, this is another approach, of course 
than I have in mind with new features or versions.


Olaf

Received on Friday, 13 January 2012 11:47:43 UTC