W3C home > Mailing lists > Public > www-svg@w3.org > March 2011

Re: Comments on SVG parameters proposal

From: Jeremie Patonnier <jeremie.patonnier@gmail.com>
Date: Thu, 3 Mar 2011 18:18:48 +0100
Message-ID: <AANLkTinGzje3iT70365opFB2sy1p9U3sjUyxW61y-o1k@mail.gmail.com>
To: robert@ocallahan.org
Cc: www-svg <www-svg@w3.org>
2011/3/2 Robert O'Callahan <robert@ocallahan.org>

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

Yes it would. But how this would be designed with the SVG2 DOM proposal to
avoid a bit of verbosity into the current SVG DOM ?


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

Same question as above :)


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

Parsing is a pain for author but adding new API needs carefulness to avoid a
"to-big-to-be-used-sainly" API that author will finally avoid or hide with
"ugly-performance" framework ;-)


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

Sure, that sounds reasonable. But what if there is a type declared somewhere
(I confess that I'm not necessarily very familiar with animation stuffs and
it's maybe something already resolved, if its the case, sorry to bother).


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

\o/


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

Well if you want to avoid verbosity, you really should consider dropping
HTML, SVG and CSS as a whole ;-)

Behind the joke, this verbosity is what make the web technology accessible
to low level tech people. It's an important part of the Web and of its
success. And If I agree that to much verbosity is not a good thing
especially with programming language such as Javascript (see the problem
with SVG DOM vs. Canvas 2D), it's important to have something easily
understandable by human being (aka. authors) on declarative technologies. In
that case, "data-" do it well IMO.


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

This is obviously a flawed design made by the author (or a malicious intend
build through a XSS/CSRF attack) and it makes no difference with your $
proposal. But even in this case, it's possible to consider restricting the
use of parameters to the rules of the same-origin policy to reduce the risk
(the svg embedded or linked inside the HTML document, can access the
parameters set in the HTML document only if they are both on the same
domain).

-- 
Jeremie
.............................
Web : http://jeremie.patonnier.net
Twitter : @JeremiePat <http://twitter.com/JeremiePat>
Received on Thursday, 3 March 2011 17:19:21 GMT

This archive was generated by hypermail 2.3.1 : Friday, 8 March 2013 15:54:47 GMT