- From: Nandini Ramani <Nandini.Ramani@Sun.COM>
- Date: Wed, 02 Nov 2005 07:13:59 -0800
- To: derhoermi@gmx.net
- Cc: www-svg@w3.org
Hello Bjoern, The Working Group has discussed your comments[1] during the last F2F meeting. [1]: http://lists.w3.org/Archives/Public/www-svg/2005May/0253.html Here is our response : > Okay, then I have some additional comments: > > * prose and schema should allow ev:event, ev:observer, ev:target > ev:handler, ev:propagate, ev:defaultAction on the > relevant elements This have been fixed : both prose and schema allow all those attributes now. > * the ev:listener element should be allowed in prose and schema The Scripting chapter now contains a full section which describes the <listener> element and the schema also defines it. > * XML Events should be a normative reference It is quite clear now, here is what the "XML Event" section says : "XML Events is an XML syntax for integrating event listeners and handlers with DOM 2 or DOM 3 Event interfaces. Declarative event handling in SVG 1.1 was hardwired into the language, in that the developer was required to embed the event handler in the element syntax (e.g. an element has an onclick attribute). SVG Tiny 1.2 does not support the event attributes (onload, onclick, onactivate, etc.). Instead SVG Tiny 1.2 uses XML Events to provide the ability to specify the event listener separately from the graphical content. " > * all events should specify whether they are cancelable Fixed in the table of events of the Interactivity chapter. > * the user interface events discussion should consider canceling > events, e.g. 13.4 lacks the note "unless an appropriate action has > been taken to prevent further processing" that was in SVG 1.1 Fixed > * it should be clarified that <ev:listener ev:event = '---' ... /> > is disallowed (http://www.w3.org/mid/40E45DC1.9020603@expway.fr) The schema already forbids it. Robin Berjon from Expway will clarify this in the prose. > * the examples should be corrected (none of the listener examples > does what it should) Fixed > * processing of <ev:listener phase="capture"> and use of ev:phase > should be clarified as SVG Tiny 1.2 does not yet support that The spec. now clearly says this : "The 'phase' attribute is defined in XML Events. In SVG Tiny 1.2 this attribute must only accept the value 'default'. The capture phase is not supported in SVG Tiny 1.2." > * it should probably be pointed out why neither isDefaultPrevented() > nor stopImmediatePropagation() are supported W3C spec. do not need to say why they don't support a feature. FYI : We can not support it because it's a Micro-DOM adapted to low-end devices which can not provide as many features as the full DOM. > * section 14.1.1 should define whether ev:listener may refer to > external handlers and if so, whether that must be supported or > is optional as in XML Events Basic Profile Fixed. The spec. now clearly says : "The 'handler' attribute is defined in XML Events. In SVG Tiny 1.2 this attribute must be an IRI reference rather than an IDREF as defined in XML Events. This attribute must only be a local IRI reference" > * ev:listener should probably be added to some module and might > need a feature string <listener> has been added to a specific module and a feature string has been associated to it. Note also that the WG decided to group <script> and <hanlder> elements into a "Scripting" module. The spec. now declares the following feature strings : http://www.w3.org/Graphics/SVG/feature/1.2/#Listener and http://www.w3.org/Graphics/SVG/feature/1.2/#Scripting > * it should be clarified whether ev:listener can have xml:id, > xml:lang, xml:space, and/or xml:base The RNG and spec. now says so. > * it should be clarified whether ev:listener may have svg > content like <svg:desc> The schema clearly says that it can't have that. > * it should be clarified which of the ev:listener and ev:* > attributes are animatable (if any), that's only defined for > ev:event at the moment Fixed. No attribute is animatable in both <listener> and <handler> elements. > * it should be clarified which interfaces ev:listener objects > implement Currently, this element implements no specific interface. > * it should be clarified what happens when the ev:listener element > is removed from the document A paragraph has been added saying : " Whenever a 'listener' element is removed (via uDOM, discard, ...), the behavior is the same as if the removeEventListener method was called on the observer element on which the event listener was registered. Note that if the 'observer' attribute is not present, the observer is the parent of the 'listener' element. " > * ev:listener dependency processing should be clarified, e.g. by > referring to XML Events 3.6 We have decided to not enforce restrictions and therefore XML Events Basic restrictions do not apply to SVGT1.2. > * error handling for XML Events errors should be clarified We have clear error handling rules in C.2 for XML Events Please respond in two weeks if you are not satisfied with the above. Regards, Vincent Mahe
Received on Wednesday, 2 November 2005 14:59:11 UTC