- From: Sean Hogan <shogun70@westnet.com.au>
- Date: Thu, 27 Aug 2009 10:34:36 +1000
- 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