[www-svg] <none>

Hi,
 
> Obviously depending on the Unicode Tab character
> doesn't
> work in all situations (such as on a mobile phone).
> We'll have to see what else we can do.

I like the idea of navigation events which are
independent from how they are initiated (by keyd or
foot paddels or what ever).

I think there shou'd be even more event's like this:

Cut/Copy
  when user starts a copy action 
  the script can then set the data( and only then)
Paste
  when user starts a paste action 
  the script can then get read access to what is being
pasted

These have no security consers because it is the user
that grants the script access to write or read the
clipboard and only when the user actually wants that
to happen.





> > 17.7.1 URLRequest interface
> Yes, but seeing as there is a lot of existing

Didn't think about that.

> > 17.9.2 Interface FileDialog
> > fileDialog.save(fileData, defaultFileName)

> What use case do you have for this?
> We already added the persistent data store (which
> has a size limit).

> Sounds a little scary to me. I can think of a nice

Imagine an SVG editor(people are working on this right
now) and the editor would like to let the user open a
file(this works in SVG1.2) edit it and then save the
artwork back to a(nother) file. Since the script
should not be allowed to just write files, it should
be allowed just as it is with opening a file, to let
the user choose what to do with the data. That is to
save it to a user selected file or cancel the
operation.
If I can send file data to a erver why then not have
the user save it to disk.

The persistent data I don't care much for that's like
cookies and could be used in basically just the way
cookies have been used. 

> dialog telling me to save a new copy of my ssh key.

Where does the SVG get your key from anyways ?
And what is wrong if the user saves it to a file?
It's the user not the script that does it.
What's whorse is that the SVG could, in case the user
loaded the key file into SVG using the dialog, send it
to the server!

I don't see any more security risk than the open
function. Actually there is less risk because the
script can only say "here user, this is some data, go
ahead if you want to save it. You may cancel too. And
BTW the size of the data is about 300k incase you
worry about your disk space."


Please give me some good reasons not to have it and
how there is sec. risks.
Many people would probably like it especially when SVG
is used as an App framework.

 
> > 17.10 Filtering DOM Events
>> f.setFilter("target=r1 AND (attrLocalName='width'
OR
>> attrLocalName='height')")
> We'll take this as input for discussion.
> Thanks for the detailed analysis!

It should not be hard to write a JS impl of the above.

Jan


__________________________________
Do you Yahoo!?
Yahoo! Mail - More reliable, more storage, less spam
http://mail.yahoo.com

Received on Friday, 19 March 2004 09:12:44 UTC