Re: [SVG1.2] 6 XML Events Integration

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