Re: Comments on SVG parameters proposal

On Fri, Mar 4, 2011 at 6:18 AM, Jeremie Patonnier <
jeremie.patonnier@gmail.com> wrote:

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

No extra work is required. Any DOM API improvements in SVG2 would simply
provide a more convenient way to access the raw base value.

Dunno if this showed up in the minutes yet, but the DOM improvement proposal
we talked about and everyone seemed to like was to introduce "px" as a
shorthand for "baseVal.value". E.g., "rect.x.px = 100 - rect.width.px;".


>
>>
>> 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 ;-)
>

Perhaps a read/write rect.x.variable property for getting/setting the
variable associated with that attribute? Returning null if it's not a
variable, of course.


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

It's a little different because data- has other uses than passing
parameters, so the author may not have intended to pass a parameter.


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

Yeah, that's an option.

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]