Need support for custom attribute prefixes

[GoogleCodeExporter]

I needed to add custom attributes to svg elements however, due to svg-edit 
element/attribute whitelisting the attributes were getting washed away. 
Attached is a patch that allows custom namespaces to be associated with 
arbitrary elements keeping with the whitelisting conventions established by 
svg-edit. I tried to think about how this could be done as an extension but it  
doesn't seem possible because of the need to access all the internal data 
structures of the object.

Original issue reported on code.google.com by adamben...@gmail.com on 23 Feb 2012 at 11:52

Attachments:

• 0003-added-support-for-custom-attribute-name-spaces.patch

[GoogleCodeExporter]

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

[GoogleCodeExporter]

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

[GoogleCodeExporter]

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

[GoogleCodeExporter]

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

[GoogleCodeExporter]

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

[GoogleCodeExporter]

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

[GoogleCodeExporter]

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

[GoogleCodeExporter]

+1, I would also be interested in this functionality.

Original comment by mor...@wissenba.ch on 5 Apr 2012 at 10:44

[GoogleCodeExporter]

Original comment by asyazwan on 5 Apr 2012 at 11:34

• Changed state: Accepted
• Added labels: NeededFor-2.7

[GoogleCodeExporter]

Original comment by bret...@gmail.com on 7 Apr 2014 at 3:38

• Added labels: NeededFor-nextversion

[GoogleCodeExporter]

Original comment by bret...@gmail.com on 7 Apr 2014 at 3:45

• Removed labels: NeededFor-2.7

[GoogleCodeExporter]

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