Open GoogleCodeExporter opened 9 years ago
I also wish this is somehow made easier to manage, especially from extensions,
without requiring users to edit sanitize.js.
However can I propose making a new event for extensions to listen to? Purely
because it seems more correct.
Either way I hope this feature will make its way to the trunk.
Original comment by asyazwan
on 24 Feb 2012 at 1:12
What kind of event are you thinking about? Are you suggesting something like a
namespace handler that can be asked if a particular attribute is supported?
This sounds like a good approach but we still need a way to register namespace
handlers, probably in santize.js
Original comment by adamben...@gmail.com
on 24 Feb 2012 at 5:20
I was thinking something like sanitize.js triggering onSourceChanged event
everytime edit-source / import / export SVG operations are done, passing
whitelist array along for extension use.
Here are currently documented event list:
https://code.google.com/p/svg-edit/wiki/ExtensionDocs
Original comment by asyazwan
on 24 Feb 2012 at 5:49
Can both of you clarify if these are custom attributes in your own XML
namespaces or are they attributes that the browser natively understands (like,
for example the onclick attribute or <script>) elements.
I think I'm in favor of allowing extensions to add sets of new namespaced
elements and attributes into the sanitizing whitelist, as the XML namespace
would be a pretty clean way to control this. It would require some
restructuring of how the whitelist is stored. Right now it's a
Map<element, Array<attribute>>
but we'd probably want it to be a
Map<namespace, <Map<element, Array<attribute>>>
or something. Frankly, it's kind of bugged me that the core SVG-edit project
allows MathML elements through when very few clients of SVG-edit actually need
it and it could be better served as an extension.
On the other hand, if you want to expand the core SVG elements/attributes that
SVG-edit allows we would want to be careful about this, since it's not clear to
me how safe this would be. For instance, it would be possible to send someone
to the demo hosted at googlecode.com (which people might naturally trust) but
make SVG-edit automatically load a potentially malicious SVG file via a data:
URI. Like this:
http://svg-edit.googlecode.com/svn/trunk/editor/svg-editor.html?source=data:imag
e/svg+xml;base64,PHN2ZyB4bWxucz0iaHR0cDovL3d3dy53My5vcmcvMjAwMC9zdmciIHhtbG5zOnh
saW5rPSJodHRwOi8vd3d3LnczLm9yZy8xOTk5L3hsaW5rIiB3aWR0aD0nMjAwJyBoZWlnaHQ9JzIwMCc
gdmlld0JveD0iMCAwIDEwMCAxMDAiPg0KICA8IS0tIEltYWdlIGZyb20gU2FtIFJ1Ynk6IGh0dHA6Ly9
pbnRlcnR3aW5nbHkubmV0LyAtLT4NCiAgPGEgeGxpbms6aHJlZj0iaHR0cDovL2Jsb2dzLm1zZG4uY29
tL2llLyIgdGl0bGU9IklFQmxvZyIgdGFyZ2V0PSJfdG9wIj4NCiAgICA8cGF0aCBkPSJNNTcsMTFjNDA
tMjIsNDItMiwzNSwxMmM4LTI3LTE1LTIwLTMwLTExeiIgZmlsbD0iIzQ3YiIvPg0KICAgIDxwYXRoIGQ
9Ik0zNiw1Nmg1NmM0LTYwLTgzLTYwLTg2LTZjMTMtMTYsMjYtMjYsMzYtMzBsLTI5LDUzYzIwLDIzLDY
0LDI2LDc5LTEyaC0zMGMwLDE0LTI2LDEyLTI1LTV6TTM3LDQzYzAtMTcsMjYtMTcsMjYsMHpNMzksODl
jLTEwLDctNDIsMTUtMjYtMTZsMjktNTJjLTE1LDYtMzYsNDAtMzcsNDhjLTEyLDM1LDE0LDM3LDM3LDI
wIiBmaWxsPSIjNDdiIi8+DQogIDwvYT4NCjwvc3ZnPg==
Imagine if that encoded SVG referenced an external JS file via a <script> tag?
Original comment by codedr...@gmail.com
on 26 Feb 2012 at 6:38
In our case it is custom attributes in our own XML namespace. Specifically we
have attributes like tgs:state that live on existing svg elements like <g> or
<svg> from our xml namespace xmlns:tgs="http://www.totalgrid.org" that we need
to be able to work with.
Original comment by adamben...@gmail.com
on 26 Feb 2012 at 8:34
In my case it's Sozi's attributes such as sozi:hide, sozi:clip, sozi:zoom, and
so on: http://sozi.baierouge.fr/wiki/en:format
Original comment by asyazwan
on 27 Feb 2012 at 12:00
Any possible resolution on this one? Likely or not for 2.6? Any updates would
be appreciated, thanks!
Original comment by adamben...@gmail.com
on 6 Mar 2012 at 11:02
+1, I would also be interested in this functionality.
Original comment by mor...@wissenba.ch
on 5 Apr 2012 at 10:44
Original comment by asyazwan
on 5 Apr 2012 at 11:34
Original comment by bret...@gmail.com
on 7 Apr 2014 at 3:38
Original comment by bret...@gmail.com
on 7 Apr 2014 at 3:45
would be nice to handle also custom attributes in normal namespace, as it's
possible in html5 browsers..
Original comment by renan.je...@gmail.com
on 12 May 2015 at 8:39
Original issue reported on code.google.com by
adamben...@gmail.com
on 23 Feb 2012 at 11:52Attachments: