- From: Dr. Olaf Hoffmann <Dr.O.Hoffmann@gmx.de>
- Date: Wed, 2 Mar 2011 18:26:43 +0100
- To: www-svg@w3.org
Jeremie Patonnier:
>This point could confused authors and should be clearly defined. At some
>point, having animated parameters is a very appealing idea but it can have
>crazy side effect. For example what will happen if I use an animated
>parameters as one of the values of a "values" attribute. See the above
>example (In the example, I assume the "value" in attributeName refer to the
>value provide by the user, if not, it's the value of the default attribute,
>this is already a big question, what is the attributeType here and how is it
>handled?) :
>
><defs>
> <ref id="myR" param="myRvalue" default="5">
> <animate attributeName="value"
You mean attributeName="default" ?
To animate the external input requires some
other approach, because this has no attributeName...
But is it useful to do it all all, if it comes from outside
anyway?
> attributeType="???"
No need to provide this...
> dur="7s" to="10"
> repeatCount="indefinite"/>
> </ref>
><defs>
>
><circle cx="10" cy="10" r="1">
> <animate attributeName="r"
> attributeType="XML"
> dur="9s"
> values="0 ; url(#myR) ; 10"
The biggest problem here is backwards-incompatibility, better to use something
like
values="0 ; 5 ; 10"
param='values="0 ; url(#myR) ; 10"'
In this case older viewers will typically ignore the new attribute param
and will use the simple value attribute with some meaningful fallback.
Newer viewers knowing already the param attribute can replace all attributes
mentioned as values with the parametric construct.
> keyTimes="0 ; 0.5 ; 1"
> repeatCount="indefinite"/>
></circle>
>
>What is the good way to interpolate a value with a changing value? I'm sure
>there are technical answers here but which one will be understandable by
>authors?
For animation there is no big problem with the animated values
itself, this can happen already now for example with values like
inherit (for properties) or currentColor (fill, stroke).
Each time the current value of url(#myR) is used.
If the referenced value animation is not discrete itself, the
referencing animation can be continuous as well - there
appears only a problem, if the question of interpolability is
not easily predictable (currently most viewers fail in such a
situation, even if it is predictable, that a fill or stroke animation
can only be discrete, because one of the animation values
is a paint server or 'none').
Another option for better backwards compatibility is to
always refer only to parametric constructs from the defs element,
for example this way:
<def>
<ref param="myRvalue"
xlink:href="#sample" attribute="fill" default="blue" />
</def>
<circle id="sample" r="10" fill="red" />
old viewers will present it always as red, new viewers will either
use the default or the external value.
Authors therefore can still provide a fallback for viewers not
interpreting this new feature.
However one cannot replace only a part of an attribute value
or some content of an element, what is anyway a problem with
the current proposal, but could be interesting:
(use as fallback an entity 'name' in the doctype for old viewers)
<def>
<ref param="name"
entity="name"
default="Ladies and Gentlemen" />
</def>
<text>Hello &name;</text>
Or something like this:
<def>
<ref param="color"
entity="myColor"
default="#f0f" />
</def>
<circle r="10" fill="&myColor;" stroke-width="2">
<animateColor attributeName="stroke" dur="60s" repeatDur="indefinite"
values="red;blue; &myColor; ;green" />
</circle>
One can already see, that this has some syntax problems as well
due to the ';', that appears here in the values list. I think, for old
viewers this is no problem, because they replace it before trying
to interprete the XML. However if there is an option that this can
change after interpretation of the XML, the viewer needs some
more complex algorithm to avoid confusion.
Olaf
Received on Wednesday, 2 March 2011 17:27:19 UTC