Re: Comments on SVG parameters proposal

Hello SVGWG

I wish to add some comments in a web author perspective on that topic
because it's a kick ass feature for people like us.
As I said during SVG Open 2010, this is something Web authors already
emulate through scripting (client side or server side) but as many feature
done this way, it's better, faster, safer if we can relay on build in
mechanism to do it.

Before commenting, I have to warn you that, as all web author, I'm not
really aware of the implementation requirements and maybe, some of my though
could appear naive in that perspective. But I will be glad if you correct me
:)

2011/3/2 Robert O'Callahan <robert@ocallahan.org>

> 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'm not really sure about that. If an author try to access the attribute
through the DOM, it's to perform two possible action :

   - Reading the attribute : In this case, he's looking for its value,
   regardless it's bound to a variable or not
   - Writing a new value : In this case, he wish to be able to push a plain
   value or bind it to a declarative variable (by opposition to a JS variable)

At some point an author could want to know if the attribute is bind to a
declarative variable and it will be good to have a way to know that through
the DOM but not by reading the value.


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

Yes and it makes things much more understandable by authors, especially if
it's possible to clearly define the contexts where it's or it's not possible
to use such parameters.


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

Web author are not always fully aware about such risk (especially the less
experienced ones). I agree that there is something that should be discusse
here. But it's not possible to fully avoid the use of URIs or URL fragments,
espacially to allow the use of the CSS url() function to make reference to
things such as clipPath, Gradient, filters, etc. Correct me if I'm wrong,
but I think it's possible to check at parsing time if it's a simple URL
fragment (starting with #) which provide minimum risk.


> == 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 point could confused authors and should be clearly defined. At some
point, having animated parameters is a very appealing idea but it can have
crazy side effect. For example what will happen if I use an animated
parameters as one of the values of a "values" attribute. See the above
example (In the example, I assume the "value" in attributeName refer to the
value provide by the user, if not, it's the value of the default attribute,
this is already a big question, what is the attributeType here and how is it
handled?) :

<defs>
    <ref id="myR" param="myRvalue" default="5">
        <animate attributeName="value"
                 attributeType="???"
                 dur="7s" to="10"
                 repeatCount="indefinite"/>
    </ref>
<defs>

<circle cx="10" cy="10" r="1">
    <animate attributeName="r"
             attributeType="XML"
             dur="9s"
             values="0 ; url(#myR) ; 10"
             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?


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

Ok, but in an author point of view, it will be good to see if some type can
by implicit (for example, if he only use numbers, assuming that it's an
number and if the variable is only used by attribute that use coordinate,
assuming that the type is "coordinate"). Is it something possible?


> These types would also be useful for authoring tools.
>

Having type is always good for tools, but sometimes annoying for authors ;)
IMHO there is something to find in-between.


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

I don't know about parsing stuffs but about CSS, it could be good to make
sure that CSS variable and SVG parameters works the same way. In a lot of
cases, authors will relay on CSS variables to deal with SVG properties (if
it come first in the implementation process because lot of them are much
more familiar with CSS than with SVG at the moment) so having a strong
common ground should be good for authors. BTW what will happen between CSS
Variable and CSS Animation? This is also something that overlap the SVG
playing ground.


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

In general, Web author are not really familiar with the <object><param
...><param ...></object> syntax because there is to few use case where it's
relevant. So there is no objection to use attributes instead of <param>
elements. If you prefer this attribute solution, I strongly encourage you to
relay on the HTML5 custom data attribute :
http://dev.w3.org/html5/spec/elements.html#embedding-custom-non-visible-data-with-the-data-attributesThat
way, web author can just use a unique behavior to deal with custom
"things" in HTML documents.


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

Yes, you're right and web author a very aware about that.


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

Ouch ! IMO this is very bad because it make the syntaxe less understandable
by introducing a new syntax complication (and it is already hard enough to
teach authors with the simplistic HTML syntaxe). As I said, it could be much
more relevant to relay on HTML5 custom data attribute that include enough
syntax complexity for authors.

I think (but I can be wrong) there is no big difference for you who
implement features between <img src="foo.svg" $text-color="red"> and <img
src="foo.svg" data-text-color="red">. And because, the HTML5 custom data
attributes are already on their way with (almost) the same purpose as the $
you propose, I really think following HTML5 here will be better for authors.


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

Well... why not, but if you have more than one parameters it will become
really hard to read (even if the name-value pairs are comma separated) maybe
with something like the following it will be easier for author :
background-image: url(foo.svg, text-color=red, my-x-pos=50). That way, it
looks more like the URL Query parameters which is something the authors are
used to read (in a UX point of view this syntax relay on preexisting habits
which make it easier to adopt by authors).

That was just my 2c.
Thanks for the job done so far :)

Cheers
-- 
Jeremie
.............................
Web : http://jeremie.patonnier.net
Twitter : @JeremiePat <http://twitter.com/JeremiePat>