Re: Can Dispatch canDispatch()?

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.

Besides all that, every event-detection technique (apart from mutation
events) will be removed from the actual problem. We may as well have a
standard test that we can hassle the vendors to valid.

Received on Friday, 28 August 2009 04:51:31 UTC