Re: Summary of animation discussion

>Jeff Schiller:
>> Hello Dean,
>> Since I've never heard of the acronym SVGA outside of monitor resolutions,
>> can you clarify whether it is the same thing as the SVG + the SMIL subset
>> defined within SVG 1.1?
>
Tab Atkins Jr.: 
>Yeah, it is.  It was just a shorthand way to refer to "SVG
>animations", rather than typing the whole phrase every time.
>
>~TJ

Because declarative animation is simply an intrinsic part of any version and
profile of SVG,  this is simply SVG - or do you call SVGB a short hand for the 
subset of SVG about basic shapes? Or SVGP- the tiny path subset? ;o)


Wouldn't it be useful to get the SYMM group interested in this issue to extent
the declarative animation part with CSS-transition like features and how to
integrate class like selectors to get everything together? They have
experience with time dependent issues - and this might avoid such 
inconsistencies/inaccessibilities as that with audio and video in the 
HTML5 draft.
I think doing this provides the most benefits for authors - simple syntax,
large amount and varity of possible applications etc.

SVG never used time containers - doing this in SVG 2 could increase the
number of use cases even more as well. 

A declarative method to pause animation would be interesting too, however
this might get complex (but I never tried to find out, how consistent the 
already existing scripted access for this is, because there is no declarative 
way for this).

Another interesting feature would be to have a declarative method to
conserve and reuse a current presentation value at time t with something
like this:
<getValue xml:id="V1" xlink:href="test1" attributeName="fill" begin="click" />
<getValue  xml:id="V2" xlink:href="test1" attributeName="fill" 
begin="click+2s" />
<getValue  xml:id="V3" xlink:href="test1" attributeName="fill" 
begin="click+4s" />
<useValue xlink:href="test1" attributeName="stroke" begin="click+6s" dur="10s" 
values="#V1;#V2;#V3" fill="freeze" />

This allows to get an advanced approach for to-animations with conserved
underlying values, what is currently typically problematic, if the
to-animations restart several times - the current approach is tricky and
due to bugs in viewers related to to-animations it does not really work in
practice.

 Olaf

Received on Friday, 5 November 2010 10:48:05 UTC