Re: Comments on SVG parameters proposal

On Thu, Mar 3, 2011 at 1:47 AM, Jeremie Patonnier <
jeremie.patonnier@gmail.com> wrote:

> 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
>
>
An API like baseVal that reads the post-parse value would work for you here.


>    -
>    - 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)
>
>
You could set baseVal to set a plain value and use setAttribute() to set it
to a variable.

However, the main reason I suggest resolving variables during content
attribute parsing is because I can't think of any other sane way to do it
:-).

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

You could use getAttribute() and then parse, or we could add new API to
baseVal for that.

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

I propose that if the type of the variable is not declared anywhere, it
should be treated as a string. Animation of strings just flips from one
value to another without interpolation.


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

If the source and destination strings are both parseable as numbers we can
automatically interpolate between them as numbers; the result would be
treated as a string and reparsed in every context where it's used. That
would probably work.

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

Using "data-" might be more verbose. Also, it means that if you write
<img src="http://evil.com/coolimage.svg" data-my-secret-stuff"">
the image (which you perhaps don't trust) gets access to all the data-
attributes on your image, which the author may not have intended.

These are relatively minor concerns though. Using data- attributes might be
the best approach.

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]