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 WGsReceived on Thursday, 27 August 2009 00:35:28 GMT
This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 22 June 2012 06:14:03 GMT