- From: Garrett Smith <dhtmlkitchen@gmail.com>
- Date: Wed, 29 Dec 2010 18:22:42 -0800
On 12/28/10, Ian Hickson <ian at hixie.ch> wrote:
> On Mon, 20 Sep 2010, Biju wrote:
>>
>> We need
>> HTMLNode.getSupportedEvents() ==> returns a text array of event names
>> HTMLNode.isSupportedEvent(eventName) ==> returns true/false
>>
>> Many times in particular version of browser we dont know whether an
>> HTMLNode/window support particular event.
>> Or what are the alternate events available, so that we can refer some
>> document or do some test to find how it can be used.
>> So I wish we had above methods available.
>
> What do you mean by "supports an event"? You can dispatch any event you
> want to any event target.
>
No response from the OP yet, so I'll chime in.
Sure, any event can be dispatched to any event target, even made up events.
However, how can a program determine if a particular event is
generated by the browser and fired at a particular object? The
`("onhashchange" in window)` test should theoretically work, but as
mentioned, that isn't interoperable at this point.
Another strategy for making inferences about event handler properties
is to set an event handler attribute, then check the corresponding DOM
property, a la `isEventSupported`. This can work but can be tricky
for window properties.
Yet another approach, mentioned recently on www-dom by Jacob Rossi
(though a similar approach was proposed by RobG on c.l.js (or was it
iPhone GG?) about two years ago), is to synthesize an event, fire it
at a target, and then check the properties of the dispatched event.
While that can give valuable information, it does not tell
specifically if the browser will create and fire event at the target.
Aside from that, the event generation APIs are just awful, and for
that, again, I've reified the proposal for extensible event synth API
that takes an interface name and a properties object to replace the
multiplicitous methods with excessive, unmemorable, and brittle
argument lists.
The proposed `eventTarget.generatesEvent` would provide a good
inference about what events will be fired at an element.
It is not intended to be comprehensive about plugins but it would be a
useful standard replacement for `isEventSupported`. I don't mind the
method name; perhaps instead `eventTarget.isEventTargetFor`.
What is stopping generatesEvent/isEventTargetFor from being considered here?
--
Garrett
Received on Wednesday, 29 December 2010 18:22:42 UTC