hasFeature and featurestrings (was: Can Dispatch canDispatch()?)

Hi, Sean-

Sean Hogan wrote (on 8/28/09 12:50 AM):
> Garrett Smith wrote:
>>
>> 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.

You seems to be making a false assumption here.  The DOM3 Events spec 
could specify feature strings for any level of detail necessary to 
provide consistent and robust reporting.  For example, we could specify 
that the set of feature strings may include a hash (or any other 
specific delimiter), then the name of the event type to be tested:

  hasFeature("Events#textInput", "")

This should return true for any browser that supports the 'textInput' 
event (the version argument is optional)... and which also supports 
hasFeature and DOM3 Events.

In fact, I considered proposing this as a replacement for canDispatch, 
but I wasn't sure it solved any of the issues that Olli brought up 
(plugin support for features, etc.), nor that we could get agreement 
from browser vendors to implement it.  hasFeature has the advantage over 
canDispatch (or hasEvent) in that it is already implemented in many 
browsers.  My proposed feature string mechanism has the advantage over 
most feature strings in that it is combinatorial... it doesn't require 
that browsers store long tables of comparison strings, but only the base 
string and the string literals of the event types, which they would have 
to store anyway.


> 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.

If the browser vendors will agree to implement this featurestring 
proposal (or some variant on it), I will put it in the DOM3 Events spec.

I do agree that this is a strong use case, but I want to be realistic 
about whether it solves the majority of use cases, and whether we can 
get interoperability on it.  I personally think this would be very 
useful for authors, assuming we get all the browser vendors on board.


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

Received on Friday, 28 August 2009 06:40:32 UTC