Re: Can Dispatch canDispatch()?

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

Regards-
-Doug Schepers
W3C Team Contact, SVG and WebApps WGs

p.s. "MUTATION EVENTS!!!!!" (yelled to the tune of "KAHHHHHNNN!!!!")


Doug Schepers wrote (on 8/26/09 3:21 PM):
> Hi, Folks-
>
> It seems that canDispatch() needs to be fixed or forgotten. So far as we
> can tell, it's not widely implemented. None of Firefox, IE, Opera, or
> WebKit seem to support it. Batik does support it [1], but I couldn't
> find any discussion of its use [2]. DOM3 Events is just a draft, so we
> can change it, if we need to.
>
> So, my questions to this list are:
> * Is the functionality in canDispatch() needed?
> ** If it's not needed, should we drop the feature, in the interest of
> interop and speed to market?
> ** If it is needed, is canDispatch() sufficiently and usefully specified?
> *** If it's not sufficiently and usefully specified:
> **** what specifically needs to be clarified, and could people propose
> wording?
> **** should we specify something else instead, and if so, what should
> the feature look like?
>
> Garrett's counter-proposal did not seem to satisfy any of the other
> implementers, and I confess that I'm skeptical that we could design
> something from scratch in the next few weeks that would solve the
> problem and get universal support. So, if we can't fix canDispatch()
> easily, I'm tempted to drop it from the spec, and approach the problem
> another way, in another spec dedicated just to event delegation.
>
> Thoughts?
>
> [1]
> http://xmlgraphics.apache.org/batik/javadoc/org/w3c/dom/events/DocumentEvent.html
>
> [2]
> http://www.nabble.com/forum/Search.jtp?forum=308&local=y&query=canDispatch
>
> Regards-
> -Doug Schepers
> W3C Team Contact, SVG and WebApps WGs
>
>
> Garrett Smith wrote (on 8/23/09 3:54 PM):
>> On Thu, Aug 20, 2009 at 4:32 AM, Stewart
>> Brodie<stewart.brodie@antplc.com> wrote:
>>> Garrett Smith<dhtmlkitchen@gmail.com> wrote:
>>>
>>>> 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?
>>>
>>> DocumentEvent.canDispatch() would seem to fit the bill, although it's
>>> not
>>> clear exactly what criteria this method is supposed to base its
>>> answer on
>>> right now.
>>
>> I see. It wouldn't really "fit the bill", unless it did, but since we
>> don't know if it does, it must seem so.
>>
>>
>> You could suggest a clarification for the text and then you
>>> don't need to add all those new methods.
>>>
>>
>> No, that "canDispatch" sounds like almost as bad an idea as
>> hasFeature. I learned not to trust crap like that quite good many
>> years ago.
>>
>> About canDispatch, if an implementation performs an internal test,
>> actually dispatching and returning the event, then it would be
>> trustable. However, creating and dispatching an event would has
>> obvious side effects.
>>
>> [...]
>
>
>

Received on Wednesday, 26 August 2009 20:16:56 UTC