W3C home > Mailing lists > Public > www-dom@w3.org > July to September 2009

Re: Can Dispatch canDispatch()?

From: Garrett Smith <dhtmlkitchen@gmail.com>
Date: Fri, 28 Aug 2009 00:01:17 -0700
Message-ID: <c9e12660908280001n4b9653a6y164df71c8f5325c4@mail.gmail.com>
To: Sean Hogan <shogun70@westnet.com.au>
Cc: DOM public list <www-dom@w3.org>
On Thu, Aug 27, 2009 at 9:50 PM, Sean Hogan<shogun70@westnet.com.au> wrote:
> Garrett Smith wrote:
>> On Thu, Aug 27, 2009 at 12:28 AM, Sean Hogan<shogun70@westnet.com.au>
>> wrote:
>>> Actually, I've changed my mind on canDispatch() and I would propose we
>>> keep
>>> it (but maybe change the name to hasEvent() as suggested by Garrett
>>> Smith.)
>> That wasn't a name change proposal; it was a straw man. really,
>> anElement.hasEvent wouldn't tell a whole lot about the event.
>> canDispatch is something that reminds me very much of hasFeature. It
>> operates on a document level and portends what feature is supported.
>> Method hasFeature never was trustworthy, and so I think that
>> canDispatch would have the same tendency. It is too far removed from
>> the actual problem.
> Yes, it is like hasFeature, but there are a few differences which may
> mean vendors try to keep it trustworthy:
> - basically hasEvent() is finer grained. It is more like <code>if
> (document['addEventListener'])</code>
>   than <code>if document.hasFeature("Events", "3.0")</code>.
> - if hasFeature() gives a negative, that doesn't give you any
> information about how much of the spec is missing. So devs don't bother
> checking it. So vendors don't bother keeping it valid.
>   If hasEvent() gives a negative then you just use your fallback. If
> it is a false negative then you also lodge a bug report with the vendor.
> - if hasFeature() gives a false positive, unless it is a major omission
> it seems pointless (and petty) to complain to the vendor (about the
> false positive).
>   If hasEvent() gives a false positive then you could justifiably
> lodge a bug report with the vendor and not bother with work-arounds.
> This would put the onus on the vendor to report the right value.

Explanation of what the proposed - EventTarget - method - hasEvent -
would potentially do, before weighing pros and cons.

1. document.body.hasEvent("click")
2. document.documentElement.hasEvent("submit")
3. document.forms[0].hasEvent("focus")

1. true  -- the body will fire click
2. false -- this element does not fire "submit" events
3. true  -- this element can, if it has a tabIdex, fire focus events

The method name "hasEvent" is probably best renamed to "firesEvent".
The documentElement does not "have" a "submit" event, but a "submit"
event could bubble up to it (in a compliant implementation), so, it
could catch a submit, and in that case, would it have it? "hasEvent"
is a bad name.

The name "firesEvent" tells what the eventTarget will do, not about
the event. This is a limitation of the feature and that is indicated
in the method name.

  * easy to use.
  * provides information about the object it is called on.

* does not provide detail about an event:
  - does it bubble?
  - does it have a timeStamp? If so, what is that?
  - what is the relatedTarget? (consider opera's implementation of
event.relatedTarget for "submit" event).
* might return false positives. I remember "oncontextment" in
document.body being reported as true in an early version of Opera 10a,
where the event was reportedly experimental (from a reliable source at

For each new event, implementers must consider "firesEvent", to make
sure that it would not return false positives, breaking working pages.

An EventTarget "firesEvent" method would provide a very simple,
standard check directly on an object.

The alternative to that would be something along the lines of creating
and dispatching an event.

Going with the suggestion of dispatchInitedEvent:

  interface EventTarget {
    boolean dispatchInitedEvent(in DOMString type,
                                        in Object

Dispatches an event onto the event target on which this method is called.

type - of type domstring
    The event type to be dispatched.

Return Value
boolean - Returns false if the default action as prevent (as if a
callback called "preventDefault" to stop it).


Usage 1:
A program could use dispatchInitedEvent to fire events and check to
see if they fired.

Usage 2:
A test framework could use dispatchInitedEvent to create and dispatch
events on objects.

Detailed information about the event is provided in the callback.

Pro: extensible. The current initXXXEvent methods tie the method name
to the sub-interface. For every new event that is created, now, an
initXXXEvent method must be created. With dispatchInitedEvent, a new
Event interface does not need to create its own initXXXEvent. Programs
can use dispatchInitedEvent in the Event super-interface, passing the
interface as the type.

Pro: simple interface. The current initXXXEvent methods use long,
unmemorable parameter lists. dispatchInited event provides a simpler

Side effects from the event firing (which could trigger other callbacks).

Harder to code than simple - firesEvent(type) - (more plumbing).

Recap two proposals:
1) firesEvent(type) - boolean. returns true if a target can fire an
event matching - type -.

2) dispatchInitedEvent(type, options) - boolean.  dispatches an event
on a target. Returns false if a callback called prevented default
action (as if by "preventDefault").

Received on Friday, 28 August 2009 07:01:56 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 20 October 2015 10:46:15 UTC