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

Re: Can Dispatch canDispatch()?

From: Sean Hogan <shogun70@westnet.com.au>
Date: Thu, 27 Aug 2009 10:34:36 +1000
Message-ID: <4A95D49C.9010807@westnet.com.au>
To: Doug Schepers <schepers@w3.org>
CC: DOM mailing list <www-dom@w3.org>
Doug Schepers wrote:
> Hi, Folks-
> A little more digging (and pestering PLH) shows that canDispatch() was 
> added because MS didn't want to implement some aspects of Mutation 
> events [1], so the decision was made to allow authors to discover if a 
> particular event is supported by the implementation [2] (look for 
> "willImplementationDispatch").
> It does seem that, once introduced, it was repurposed for the more 
> general case, such as detecting if a Custom Event would be dispatched 
> [3].  I am not sure these are quite the same use case, and I think 
> this introduces even more ambiguity into canDispatch().
> To me, this seems like evidence that we should drop canDispatch() for 
> now, and approach the problem from a different angle, with proper use 
> cases and requirements.
> If I don't hear objections in the next two weeks, I will drop this 
> method from the next draft.  I have already marked it as At Risk.
> [1] 
> http://www.w3.org/2002/07/DOM-Level-3-Events-issues/issues.html#pettit8
> [2] http://www.w3.org/DOM/Group/meetings/m20020828.html
> [3] http://lists.w3.org/Archives/Public/www-dom/2002JulSep/0167.html
I can't read [2], but [1] and [3] are clear that canDispatch(evType) 
tests if the implementation WILL generate events of specified type. The 
current text (which says CAN generate) is ambiguous, but I would now 
assume this was to match the (inappropriate) method name.

If this method could be implemented reliably then it should be kept. It 
probably wouldn't be so I suppose it should be dropped.

What would count as proper use cases and requirements for the 
replacement? Surely these have already been presented?

> Regards-
> -Doug Schepers
> W3C Team Contact, SVG and WebApps WGs
Received on Thursday, 27 August 2009 00:35:28 UTC

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