Comments on SVG parameters proposal

http://www.w3.org/TR/2009/WD-SVGParam-20090430/

I think parameters should be introduced as a modification to the way we
parse SVG attributes. That means the DOM attributes always contain the
variable names, serializing the DOM always outputs the variable names, etc.
Currently I think that's not defined.

I think we should define a general notion of "the parameters of a document",
as an unordered map from name to its value (and possibly type, see below).
Then we can define syntax for setting the parameters in each context where a
document or fragment can be referenced.

I'm a bit worried about security issues with passing URIs as parameters. For
example, suppose an image at google.com uses fill="$param1". An attacker at
evil.com can potentially do <img src="http://www.google.com/images/img.svg"
$param1="url(https://www.google.com/dosomethingevil)"> to arrange for a
same-origin load of that URL, which might be treated with special authority.

== Types ==

We'll want to be able to animate parameters, but it would seem quite
difficult to do if parameters are just strings whose interpretation depends
entirely on the context they're used in the subresource. We'd probably have
to propagate animations into the subresource, which will be tricky
especially when the same resource is used multiple times with different
parameters; we'd also have to deal with the fact that the subresource
timeline could be different from the timeline of the usage site. I think it
would be simpler to let animation and interpolation happen at the usage
site.

This would mean associating an optional type with each parameter. If at all
possible, the types should be assigned by the subresource, with markup to
indicate the types of (some of) its parameters. Parameters for which we
don't know the type would be treated as strings and hence
non-interpolatable.

These types would also be useful for authoring tools.

Having types declared in the subresource might not work well with parameter
values set in CSS, since for CSS parsing we'd want the types to be known at
CSS parse time. But maybe we can work around that by deferring parsing of
parameter values until the subresource has loaded.

== Syntax for elements that refer to documents ==

The <object><param ...><param ...></object> syntax is not something we
should follow because it's nasty when you have a partial document; you have
to create the <object> element but you may not have all the <param>s yet, so
you have to delay instantiating the subobject. Instead, I think parameters
should be passed via attributes on the including <img>, <object> element
etc.

I also think URI query parameters should not be used since that will
interfere with caching.

One idea that might help sync with CSS variables would be to refer to
parameters with $foo syntax, and also allow $foo syntax to set parameters
via attributes, e.g. <img src="foo.svg" $text-color="red">.

== CSS syntax ==

Using name-value pairs means the CSS syntax might have to be something like
background-image: url(foo.svg, text-color red)

Rob
-- 
"Now the Bereans were of more noble character than the Thessalonians, for
they received the message with great eagerness and examined the Scriptures
every day to see if what Paul said was true." [Acts 17:11]