RE: Fixes needed (DOM L3 Events, CustomEvent)

Daniel Cazzulino wrote:

>2 - Interface CustomEvent: it says: "It is intented to be used by the DOM 
>implementation to access the underlying while ...". First, it should be
>"INTENDED", second, access the underlying WHAT?
>And regarding this interface, how is the DOM implementation supposed to
change the >currentTarget and phase attributes if they are readOnly in the
Event interface and >it doesn't have the CustomEvent methods? It seems to me
that all events must have >these two methods, or maybe the attributes should
be made read/write.

Definitely this section is filled with typos (how about the currentPahse
that appears later).

Current implementations of Events have private knowledge of how to change
the currentTarget and phase attributes of their events.  CustomEvent would
only be used when an event was not recognized as an internal event.

There are other missing pieces too, for example, there is no method for the
implementation to determine if stopPropagation() or preventDefault() was
called.

In general, it is a dangerous thing to let anyone other than the
implementation write to currentTarget and eventPhase.  Though the prose says
that only the implementation should call it, there would be nothing
prohibiting a rouge script from holding on the the event and messing with
the phase and target at will.

It would seem a lot cleaner for CustomEvent to be part of the
implementation, created by DocumentEvent.createEvent("UserEvents") and allow
the caller to initialize it with an arbitrary object:

interface CustomEvent : Event {
    readonly attribute EventDetail detail;
    void initUserEvent(String eventTypeArg, boolean canBubbleArg,
		boolean cancelableArg, EventDetail detail);
}

Where EventDetail would be Object for most bindings.  Not quite as pretty to
use as adding your own event interface, but it should offer the same
capability with less issues.

Received on Wednesday, 27 March 2002 19:19:43 UTC