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 12:33:37 +0300
Message-ID: <4A9652F1.5090109@helsinki.fi>
To: Sean Hogan <shogun70@westnet.com.au>
CC: Doug Schepers <schepers@w3.org>, DOM mailing list <www-dom@w3.org>
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.


-Olli


> *Use cases*
>
> To start this thread Garrett said:
>
> The inability to easily and accurately detect events is a problem.
> Programs want to know if an event is implemented at runtime. If it is,
> then the feature can be used. If not, it a fallback stratety is in
> order. Many new event types are being created and implemented. How can
> a program feature-test to see if they are implemented?
>
>
> This covers every event, but the most relevant events of today would be
> mouseenter, mouseleave and textInput.
> These events could be simulated if it is detected that they aren't
> supported natively.
>
>
> *Current work-arounds*
>
> What events can currently be detected?
> Mutation Events can be tested for explicitly on any platform.
> I don't know of any way to test for the others using standard APIs.
>
> You can test for many events on HTML elements in today's top browsers. See:
> http://thinkweb2.com/projects/prototype/detecting-event-support-without-browser-sniffing/
>
>
> I don't know of any way to test for textInput, but at the moment testing
> for the "TextEvent" module suffices since textInput is the only event in
> that module.
>
> Note that:
> - none of these tests are more trustworthy than canDispatch() would be
> - these tests only apply to browsers and only to events that may be
> added via inline registration
>
>
> *Requirements*
>
> - reports whether the implementation will generate trusted events of the
> specified type.
>
>
>
>
Received on Thursday, 27 August 2009 09:34:17 GMT

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