Re: Can Dispatch canDispatch()?

On 8/28/09 10:01 AM, Garrett Smith wrote:
> On Thu, Aug 27, 2009 at 9:50 PM, Sean Hogan<shogun70@westnet.com.au>  wrote:
>> Garrett Smith wrote:
>>>
>>> On Thu, Aug 27, 2009 at 12:28 AM, Sean Hogan<shogun70@westnet.com.au>
>>> wrote:
>>>
>>>>
>>>> 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.)
>>>>
>>>>
>>>
>>> That wasn't a name change proposal; it was a straw man. really,
>>> anElement.hasEvent wouldn't tell a whole lot about the event.
>>>
>>> canDispatch is something that reminds me very much of hasFeature. It
>>> operates on a document level and portends what feature is supported.
>>> Method hasFeature never was trustworthy, and so I think that
>>> canDispatch would have the same tendency. It is too far removed from
>>> the actual problem.
>>>
>>>
>>>
>>
>> Yes, it is like hasFeature, but there are a few differences which may
>> mean vendors try to keep it trustworthy:
>>
>> - basically hasEvent() is finer grained. It is more like<code>if
>> (document['addEventListener'])</code>
>>    than<code>if document.hasFeature("Events", "3.0")</code>.
>>
>> - if hasFeature() gives a negative, that doesn't give you any
>> information about how much of the spec is missing. So devs don't bother
>> checking it. So vendors don't bother keeping it valid.
>>    If hasEvent() gives a negative then you just use your fallback. If
>> it is a false negative then you also lodge a bug report with the vendor.
>>
>> - if hasFeature() gives a false positive, unless it is a major omission
>> it seems pointless (and petty) to complain to the vendor (about the
>> false positive).
>>    If hasEvent() gives a false positive then you could justifiably
>> lodge a bug report with the vendor and not bother with work-arounds.
>> This would put the onus on the vendor to report the right value.
>>
>
> Explanation of what the proposed - EventTarget - method - hasEvent -
> would potentially do, before weighing pros and cons.
>
> 1. document.body.hasEvent("click")
> 2. document.documentElement.hasEvent("submit")
> 3. document.forms[0].hasEvent("focus")
>
> 1. true  -- the body will fire click
> 2. false -- this element does not fire "submit" events
> 3. true  -- this element can, if it has a tabIdex, fire focus events
>


So hasEvent/firesEvent means "an event called XXX may be dispatched to
this event target at some point".
Sounds like that could lead to similar problem what DOMSubtreeModified
has. A browser may say it supports DOMSubtreeModified, if it even 
theoretically dispatches the event once.

(And because extensions/plugins/greasemonkey may dispatch random events, 
hasEvent/firesEvent could always return true.)

Nit, 2) could return true for example if documentElement is <form>.



> The method name "hasEvent" is probably best renamed to "firesEvent".
> The documentElement does not "have" a "submit" event, but a "submit"
> event could bubble up to it (in a compliant implementation), so, it
> could catch a submit, and in that case, would it have it? "hasEvent"
> is a bad name.
>
> The name "firesEvent" tells what the eventTarget will do, not about
> the event. This is a limitation of the feature and that is indicated
> in the method name.
>
> Pros:
>    * easy to use.
>    * provides information about the object it is called on.
>
> Cons:
> * does not provide detail about an event:
>    - does it bubble?
>    - does it have a timeStamp? If so, what is that?
>    - what is the relatedTarget? (consider opera's implementation of
> event.relatedTarget for "submit" event).
> * might return false positives. I remember "oncontextment" in
> document.body being reported as true in an early version of Opera 10a,
> where the event was reportedly experimental (from a reliable source at
> Opera).
>
> For each new event, implementers must consider "firesEvent", to make
> sure that it would not return false positives, breaking working pages.
>
> An EventTarget "firesEvent" method would provide a very simple,
> standard check directly on an object.
>
> The alternative to that would be something along the lines of creating
> and dispatching an event.
>
> Going with the suggestion of dispatchInitedEvent:
>
> =====================================================
> ----------------------------------------------
>    interface EventTarget {
>      boolean dispatchInitedEvent(in DOMString type,
>                                          in Object
> options);
> ------------------------------------------------
> dispatchInitedEvent
>
> Dispatches an event onto the event target on which this method is called.
>
> Parameters
> type - of type domstring
>      The event type to be dispatched.
>
> Return Value
> boolean - Returns false if the default action as prevent (as if a
> callback called "preventDefault" to stop it).
>
> =====================================================
>
> Usage 1:
> A program could use dispatchInitedEvent to fire events and check to
> see if they fired.
>
> Usage 2:
> A test framework could use dispatchInitedEvent to create and dispatch
> events on objects.
>
> Pro:
> Detailed information about the event is provided in the callback.
>
> Pro: extensible. The current initXXXEvent methods tie the method name
> to the sub-interface. For every new event that is created, now, an
> initXXXEvent method must be created. With dispatchInitedEvent, a new
> Event interface does not need to create its own initXXXEvent. Programs
> can use dispatchInitedEvent in the Event super-interface, passing the
> interface as the type.
>
> Pro: simple interface. The current initXXXEvent methods use long,
> unmemorable parameter lists. dispatchInited event provides a simpler
> interface.
>
> Con:
> Side effects from the event firing (which could trigger other callbacks).
>
> Harder to code than simple - firesEvent(type) - (more plumbing).
>
> Recap two proposals:
> 1) firesEvent(type) - boolean. returns true if a target can fire an
> event matching - type -.
>
> 2) dispatchInitedEvent(type, options) - boolean.  dispatches an event
> on a target. Returns false if a callback called prevented default
> action (as if by "preventDefault").
>
> Garrett
>
>

Received on Friday, 28 August 2009 09:55:05 UTC