Re: Comments on SVG parameters proposal

Jeremie Patonnier:

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

Well I think, I would like to provide both in a simple way. 
This is already a problem with SVGT1.2 and SVG1.1.
feature-strings are often a problem, because different 
authors and developers of viewers will have typically different
ideas on what it means that a feature is interpreted.
With a fussy interpretation no current viewer should indicate
for any feature a correct implementation, because it is known,
that all have bugs ;o)
My tests on feature switches have shown, that they were never
usable. Some viewers had always unexpected behaviour and
imcomplete implementation of the switch feature itself. Well and
the answers/choices of viewers are often surprising as well ;o)
It exposes more the characters of the developers than the capabilites
of the viewer ;o)

SVG has several mechanisms for fallbacks, what is good, why not
for such parameters. Still the document might be usable for old viewers
if only a few new features are used in it with a meaningful fallback for
old viewers.

Of course, if the document relies on new features, it might be the
best to provide simply a switch to a warning ;o)
But of course, this would be already the task for the fewer, if a newer
version of SVG is given in the document than the viewer knows.
The adobe plugin provides such a warning, if a doctype is used -
therefore unfortunately not for SVGT 1.2, where it really might matter ;o)
Typically other viewers leave the audience alone with problem and 
no one can rely on them on the question, whether the display of
an SVG is complete and correct ;o) 

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

Well, it works in several viewers with inherit or currentColor or something
like that as long as they refer really to interpolable colors.
But many viewers have already problems to display an animation correctly,
if something like values="red;green;none;blue" - surely this cannot be
animated continuously, but several start anyway with a continous animation,
it calcMode is not explictly set to discrete, what is not really necessary 
according to the definition of calcMode, because it is simply to see, that
it is not possible to interpolate between the values. With user interaction
however really problematic situations can appear. There are situation,
where the problems becomes prominent, after the animation has already
started. The reason for this is, that fill and stroke are overloaded with
paint servers and 'none'. This is not a general problem for SMIL animation.
Following strictly SMIL, animation of fill and stroke could be only discrete,
because it is possible that non interpolable values appear. Obviously
we want continuous color animation. This problem is bad design of these
properties in SVG already - but now a little bit late to change.
I think, most other attributes or properties do not have this specific problem
and therefore there will be no new problem for them with parameters, 
fortunately. The problem for stroke and fill however will be even more
prominent with a parametric construction.

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

Well, should be simple to construct a mechanism in SVG2 to address for
example a class instead of a fragment identifier - indeed old and pretty 
useful idea to improve SMIL/SVG animation.
Even the approach above can use multiple ref elements to propagate
the same parameter to different elements. But of course, this is not very
elegant to use always a group of ref elements.

The main advantage here is, that the parameter references are
collected in the defs, it is easier to adminstrate as with an approach,
where the parameter contructions are spread all over the document.
Of if handled in the same way as animation elements, the author has
the choice, how to organise the source code. To have the choice is
typically a good idea, because we can assume, that different 
authors have different tastes and habits to organise their documents ;o)


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

Well, at least it is simple to use and entities are already in common use 
within SVG documents. Indeed, entities really work right now.
This is a nice method to modify parameters already now in static
documents at the top of the document without looking through the
complete source code.
Authors familar with HTML will be often confused - but the main
reason for this is within HTML or how typical user agent interprete HTML.
XML and SVG fortunately are much simpler than HTML, everything one
learns here has much more effect and consistence ;o)

Something like values="0 ; url(#myR) ; 10"
really corrupts current interpretation of the syntax.
values="0 ; &myR; ; 10" is something, that already works now and
with current SVG viewers, if &myR; is defined on top.
The only new thing would be, that one can change the definition
of &myR; from outside the document.

Common to all these approaches is, that they are not invasive, they
do not corrupt the syntax or interpretation of syntax by current viewers.
And because we know, that some viewers can be 5 or even 10 years
around, this is a big advantage.

Olaf

Received on Thursday, 3 March 2011 18:51:52 UTC