Re: Can Dispatch canDispatch()?

On Fri, Aug 28, 2009 at 2:54 AM, Olli Pettay<Olli.Pettay@helsinki.fi> wrote:
> 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.
>

That could be a problem, yes. I would not generally rely on mutation
events for production code.

What you've touched upon is more an issue of the object having
potential to fire the event, but not knowing under what conditions
that will or will not happen. It's a limitation to the method. I
suppose - canFireEvent - is perhaps more apt.

I've elaborated a little more below.

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

I don't understand how greasemonkey could affect the outcome of -
firesEvent -. Can you explain that? I don't understand the problem of
plugins dispatching random events causes issues, either.

Where would - firesEvent - always return true? Please explain the scenario.

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

Theoretically yeah. I don't know a browser that supports that.

A limitation to - firesEvent - is that it doesn't say under what
conditions the event will fire.

Suppose a new event, take "domfocusin" event, for example, makes it in
D3E TR (for better or worse). Now suppose a program wants to know if
"domfocusin" is implemented and can fire. The problem is that the
object in question may have /potential/ to fire the event, but would
need certain preconditions met before that would happen.

<input disabled type="text">
theInput.firesEvent("domfocusin"); // true.

theInput fires a focus event when it receives focus. But look, its
disabled! How will it get focus?

Or how about:-

<img style="opacity: 0;">

theImg.firesEvent("click"); // true, or what about MSIE?
theImg.style.visibility = "hidden";
theImg.firesEvent("click"); // true.

The possibility of the event firing causes - firesEvent - to return
true, but that doesn't tell the program under what conditions this
will happen. So, evTarget.firesEvent is an inference check.

The contending - document.implementation.hasFeature - is also an
inference check. The hasFeature method provides information about the
"implementation" object, and not the actual object in question. It
indicates a generalization of what an implementation claims it does
and that is a weaker, riskier inference.

The other problem is where you have an experimental feature that is
shipped, not done:-

theImg.firesEvent("contextmenu");

Where - theImg - has potential to dispatch a "contextmenu" event, but
the implementation hasn't made it yet possible to trap that event in
the UI, and so it won't ever happen.

That is a case that where a program should have a graceful degradation
strategy, so that if disabling the context menu (and replacing it with
its own hand-rolled context menu) failed, that the user could still
perform the functionality otherwise (perhaps by using kbd shortcuts,
buttons, a sticky menu).

[snip remainder]

Garrett

Received on Friday, 28 August 2009 22:36:24 UTC