- From: Maciej Stachowiak <mjs@apple.com>
- Date: Mon, 1 May 2006 02:44:49 -0700
- To: Robin Berjon <robin.berjon@expway.fr>
- Cc: www-svg@w3.org
On Apr 28, 2006, at 3:36 AM, Robin Berjon wrote: > On Apr 25, 2006, at 20:09, Maciej Stachowiak wrote: >> So script code couldn't call these methods on the global object, >> and the UA would not call them on the global object, so claiming >> the global object implements the interface makes no sense. > > The Ecmascript bindings don't include this interface, so the point > is, I believe, eventually moot. However, by "script" I meant to include Java as well. There would be no reason for Java to user this interface on the global object either, and a Java "script" would not be allowed to use the interface per the spec. The intent of the interface is for Java event handlers to implement it, so that the implementation can call the handler and tell it to register itself. It just doesn't make sense that the global object would implement it too. > Thanks for your feedback, please let us know if this doesn't > address your concerns, I don't get why the global object is required to implement an interface that application code may never call. This seems like a long-ago error in the specification, I do not understand why the SVG WG wishes to retain the error, regardless of how much practical effect it may have. Just to be super clear on this: - The global object implementing EventListenerInitializer2 is *not* required for Java event handlers to work. In fact, it plays absolutely no part in registering Java event handlers. - Neither Java handler/script code nor ECMAScript handler/script code may call the one method in this interface on any object. So you end up with a method that only the implementation would be allowed to call, but it doesn't want or need to ever. Is it the position of the SVG WG that despite this SVGGlobal should still inherit from EventListenerInitializer2? Regards, Maciej
Received on Monday, 1 May 2006 09:44:58 UTC