- From: Antoine Quint <ml@graougraou.com>
- Date: Sat, 15 Nov 2003 17:39:15 +0100
- To: "Jim Ley" <jim@jibbering.com>
- Cc: www-svg@w3.org
Hi Jim, > 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 appreciate your position, although it is rather extreme to say that it adds authoring confusion and spec complexity :) I would need to re-read the current draft section, but I'm sure we can clear those two problems with careful wording comparing with the existing attribute-based event listeners. Namespace support is really useful, and using XML Events the way they are integrated today would only provide a better (although I feel you might argue this) alternative to attribute-based event listeners rather than bring inline handlers to the level of DOM Level 3 Events functionality. This needs addressing. > 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? I don't understand this example as the <handler> element can only contain code, as the first sentence of section 6.1 states: "The handler element is similar to the script element: its contents, either included inline or referenced, are code that is to be executed by the scripting engine(s) used by user agent." Antoine -- Antoine Quint <aq@fuchsia-design.com> W3C SVG Working Group Invited Expert SVG Consulting, Teaching and Outsourcing Fuchsia Design <http://www.fuchsia-design.com/>
Received on Saturday, 15 November 2003 11:42:43 UTC