- From: Olli Pettay <Olli.Pettay@helsinki.fi>
- Date: Thu, 27 Aug 2009 13:09:29 +0300
- To: Sean Hogan <shogun70@westnet.com.au>
- CC: Olli@pettay.fi, Doug Schepers <schepers@w3.org>, DOM mailing list <www-dom@w3.org>
On 8/27/09 12:57 PM, Sean Hogan wrote: > 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(). > What has trusted events to do with hasEvent()? (AFAIK, trusted events are gecko specific thing.) -Olli
Received on Thursday, 27 August 2009 10:10:08 UTC