- From: Jim Ley <jim@jibbering.com>
- Date: Sat, 15 Nov 2003 14:54:24 -0000
- To: www-svg@w3.org
Hi, I'm concerned on the value of XML Events, SVG 1.2 is a multi-namespace aware application, it has specific support for DOM 3 events, so we need multi-namespace events, I do not feel the specification should introduce spec complexity, implementation cost, and authoring confusion to simply add a non-namespace aware inferior method of seperating script and content than DOM 3 provides. I see two solutions to this: Ignore XML events, until there are a Namespace aware version to use. Invent an SVG specific extension to add namespace handling to the events. The first is my clear favourite. You could also of course carry on and include the rather useless crippled XML events, but I don't see how valuable this would be, for the added cost of including. If it does stay in: In the following situation: <handler type="text/ecmascript" ev:event="click"> <foo:offset xmlns:foo="urn:chicken#" value="10"/> alert('a'); </handler> What is passed to the script engine? Why is script the inferior brother to Java in the example (an external java has init called, javascript does not) how is the user agent able to understand the difference? I do not believe it is appropriate for a specification not to be language neutral and <handler id="myClickHandler" type="application/java" xml:base="http://example.com/myJar.jar" xlink:href="#com.example.MyXMLEventHandler"/> <param name="offset" value="10"/> </handler> <handler id="myClickHandler" type="text/ecmascript" xml:base="http://example.com/myJar.jar" xlink:href="foo.js"/> <param name="offset" value="10"/> </handler> Should be identically capable, otherwise porting a Java versioned SVG file to javascript will be impossible. Due to these problems, I'd like to see it removed as before. Jim. [This I feel strong enough to be an issue if still relevant before last call phase.]
Received on Saturday, 15 November 2003 09:55:24 UTC