Re: hasFeature and featurestrings

Doug Schepers wrote:
> 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.

I don't see this working. If hasFeature("Events#evType", "") returns 
false does that mean evType isn't supported or hasFeature doesn't 
support event reporting.  I wouldn't trust hasFeature("Events", "3.0") 
to tell us that event reporting is valid, but I suppose we could check 
hasFeature("Events#click", "").

With document.hasEvent() we can test if the function exists and then 
fallback to other techniques for event detection.

Who can tell which choice will result in a more reliable test, but my 
gut-feeling is that hasFeature("Events#evType", "") will be implemented 
haphazardly, won't be relied on, won't be maintained, whereas hasEvent() 
will be added when it's ready and application devs will report when it 
is wrong.

Maybe all I'm saying is that I don't think anyone cares about 
hasFeature(), lets pick a new method whose reason for existence is event 
support.

Received on Saturday, 29 August 2009 23:24:48 UTC