- From: Sean Hogan <shogun70@westnet.com.au>
- Date: Thu, 27 Aug 2009 19:57:11 +1000
- To: Olli@pettay.fi
- CC: Doug Schepers <schepers@w3.org>, DOM mailing list <www-dom@w3.org>
Olli Pettay wrote: > On 8/27/09 10:28 AM, Sean Hogan wrote: >> Doug Schepers wrote: >>> Hi, Sean- >>> >>> Sean Hogan wrote (on 8/26/09 8:34 PM): >>>> 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? >>> >>> The same as with any feature request... any solid explanation of a >>> real-world use that can't already be done via script, and which >>> implementers agree they would support, would serve as a use case. The >>> requirements would be those things which must be solved, or must be >>> avoided, in designing the feature to solve the use case. >>> >>> >>>> Surely these have already been presented? >>> >>> Could you elaborate? >>> >> 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.) >> > > > But how would the hasEvent() work with plugins, extensions or > greasymonkey scripts? All those can create random events using > the normal DOM Events API. > If they want to dispatch trusted events they will have to register with the browsers internal events table. Otherwise they can always provide their own equivalent of hasEvent().
Received on Thursday, 27 August 2009 09:58:07 UTC