- From: Stewart Brodie <stewart.brodie@antplc.com>
- Date: Thu, 20 Aug 2009 12:32:36 +0100
- To: Garrett Smith <dhtmlkitchen@gmail.com>
- CC: DOM mailing list <www-dom@w3.org>
Garrett Smith <dhtmlkitchen@gmail.com> wrote: > The inability to easily and accurately detect events is a problem. > Programs want to know if an event is implemented at runtime. If it is, > then the feature can be used. If not, it a fallback stratety is in > order. Many new event types are being created and implemented. How can > a program feature-test to see if they are implemented? DocumentEvent.canDispatch() would seem to fit the bill, although it's not clear exactly what criteria this method is supposed to base its answer on right now. You could suggest a clarification for the text and then you don't need to add all those new methods. The DOM Level 3 Editor's Draft says: > > canDispatch introduced in DOM Level 3 > > Tests if the implementation can generate events of a specified type. > > @@ what is the use case for this? Perhaps to test if an implementation > > supports a particular event, such as an event from an uncommon language, > > or a custom event? Or what does the "implementation can generate" mean? > > -Olli > > namespaceURI of type DOMString > > Specifies the Event.namespaceURI of the event. > > type of type DOMString > > Specifies the Event.type of the event. > > Return Value > > boolean: true if the implementation can generate and dispatch this event > > type, false otherwise. > There should be a simple way to create and fire an event. > > interface DocumentEvent { > Event createInitedEvent(in domstring type, in Object options) > raises(dom::DOMException); > } > In createInitedEvent, the type of event created is determined by the > string arg /type/, which is a prefixed with a DOM Interface (as a > string) followed by ".", followed by the event type. The event is > inited with the /options/. This is a "map" of options that the event > has, such as - offsetX - , - pageY - , etc. I don't like this interface at all, for several reasons: I think it unwise to add it to DocumentEvent - what about events that are nothing to do with documents? Event names now need to be parsed to extract the interface name and the event type name (currently, that isn't required). At least have them as two separate parameters if you want to do this. I don't like Object being passed to a DOM method. The moment you permit arbitrary JS objects in a DOM API, the implementation of that method has to deal with so many more problems (e.g. dealing with infinities, NaNs, other objects). There's nothing to stop you assigning additional properties to the Event object after you've initialised it. > DOM 2 Events provides "createEvent(type)", but then required an > additional step initEvent or initMouseEvent. Method initMouseEvent > takes 15 arguments, none of them are memorable. It is painful to use. Honestly, how often does scripting wish to simulate UIEvents, MouseEvents, KeyboardEvents, MutationEvents or MutationNameEvents? The only use case I can think of is a test harness that's trying to drive an application under test. -- Stewart Brodie Software Engineer ANT Software Limited
Received on Thursday, 20 August 2009 11:33:16 UTC