Re: Comments on SVG parameters proposal

2011/3/2 Dr. Olaf Hoffmann <Dr.O.Hoffmann@gmx.de>

>
> You mean attributeName="default" ?
> To animate the external input requires some
> other approach, because this has no attributeName...
>

Absolutely, it was just an example to figure out an animated parameters
which the value is set by the author outside SVG.


> But is it useful to do it all all, if it comes from outside
> anyway?
>

Who knows, sometimes authors can have really crazy ideas :-)


> ><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.
>

There is a fundamental question here. As an author that want to use SVG 2
features, do I really want to be backwards compatible? After all, it's known
that this feature is unsupported by legacy viewers. If I really want to be
backward compatible I guess that I wish to relay on other existing mechanism
available on legacy viewers such as the <switch> element which is much more
efficient to deal with SVG feature detection and can allow me to do some
real fine tunning on my SVG design.


>  >             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').
>

Ok, I'm not necessarily very familiar with animations, but it's good to know
that the issue is raised (even if not well implemented by viewers).


> 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" />
>

He? Well this make parameters not as useful as they could be. With that,
they can be used by one element only. To be honest, this would be a great
disappointment for authors because if they have parameters, they'll expect
to be able to use them multiple times, as a variable can be.

The idea of referring from <defs> to element could be acceptable by authors
if there is a mechanism to perform multiple reference such as the one
proposed to improve animations : http://brian.sol1.net/svg/pres/SVG 2
Animation.html#(35)
<http://brian.sol1.net/svg/pres/SVG%202%20Animation.html#%2835%29%20>


> 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>
>

I'm not sure about that. Beyond the problems this idea raised to produce a
generic XML Schema or DTD for SVG or to simply parse the document, authors
coming from HTML are a lot confused by XML entities and I'm not sure that
will help them to understand both entities and parameters. But I agree that
something is missing here in the proposal.


>
> 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
>
>
-- 
Jeremie
.............................
Web : http://jeremie.patonnier.net
Twitter : @JeremiePat <http://twitter.com/JeremiePat>