Re: SVG param(eters)

Hi, Dr. Olaf-

I'd prefer not to go in this direction.  Yes, this is more powerful... 
but if you want this much power and flexibility, you should probably be 
using javascript or clientside XSLT to manipulate or transform the DOM.

The goal of Param is to provide a very simple, intuitive model that is 
easily understood even by people who don't know SVG, and is easily and 
interoperably implementable.  Introducing complexity of this degree 
risks crossing that rubicon.

I've heard other feedback that Param should be made more powerful, in 
much the manner you describe.  But I believe that what we have right now 
hits the sweet spot between utility and complexity.  These are 
interesting ideas for a later expansion, or even for a wholly different 
mechanism, but I want to resist complicating Param beyond its original 
scope, at least for v1.

Regards-
-Doug Schepers
W3C Team Contact, SVG and WebApps WGs


Dr. Olaf Hoffmann wrote (on 12/1/09 6:38 AM):
> Doug Schepers:
>>I'm not terribly fond of entities myself... why not simply set the
>>textcontent of the addressed element?
>
> Well, the usual entity construction is not very friendly for authors,
> but if you want just a part of an element content changed
> or more than one part changed independently from others -
> or think about a value list for animation, if you do not need to
> change all values, just one or two. Or within path data one can
> add a subpath for example reversing 'inside' and 'outside'
> and so on. This is a very powerful tool.
> For text content else one has to work around this limitation to
> the complete content with a lot of tspan or tref - possible too for
> graphical text content, but currently not for the alternative text
> content like that of title and desc.
>
> But of course, with a general approach there can be both
> relatively simple options with limited possibilities covering
> major use cases and some advanced options for
> 'experts' or advanced users with much less limitations.
> Authors can learn to use it, starting with the simple options,
> still having the chance to do more interesting things later.
> And this entity 'injection' looks like a very general option to
> change content. Of course, it has the potential to
> corrupt the document structure as well, if the wrong
> things are inserted. This would be an obvious
> argument against this general entity approach.
> The approach for the direct change of attribute values
> of identificable elements can contain a check frome
> the viewer for valid values of course.
> Indeed protection rules in the interpretation of such an
> entity feature  looks difficult. On the other
> hand, everyone can anyway save any SVG file,
> add some stupid content, which corrupts the file,
> there is no big difference to the approach of corrupting
> the file with stupid parameter values ;o)
>
> Another problematic issue with those dynamic entities is,
> that older programs do not interprete them and they
> may stop presentation due to unkown entities within the file.
> The only - again not very author-friendly - way to
> avoid this, is to say, that only those entities can be
> changed, which have already a fallback value defined
> within the document - with this restriction there might
> be a chance for a check for nonsense as well. The fallback
> is only replaced, if the replacement has the same structure
> as the fallback - but not easy to specify such a rule in detail ...
>
> Indeed, because those entities are very powerful, it is
> difficult to specify how to insert them with such a parameter
> method without creating a possibility to do too much nonsense
> with it.
>
> Olaf

Received on Tuesday, 1 December 2009 17:18:46 UTC