Re: SVG param(eters)

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 11:41:12 UTC