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

Re: Can Dispatch canDispatch()?

From: Olli Pettay <Olli.Pettay@helsinki.fi>
Date: Thu, 27 Aug 2009 13:09:29 +0300
Message-ID: <4A965B59.60703@helsinki.fi>
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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 22 June 2012 06:14:03 GMT