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