Re: Fwd: DOM event detection

Hi, Garrett-

Garrett Smith wrote (on 12/23/10 9:39 PM):
> On 12/22/10, Doug Schepers<schepers@w3.org>  wrote:
>>
>>  Many people suggest a more active feature-testing approach (e.g. testing
>>  to see if an event will fire, or if a method exists), but I believe that
>>  the current draft of DOM3 Events meets your needs.  You can use the
>>  existing .hasFeature() method along with discrete event interface and
>>  event name feature strings to detect support for any event in a
>>  conforming DOM3 Events UA.
...
>
> So in a nutshell:
>
> var HAS_TEXTINPUT_EVENT = document.implementation
>    &&  document.implementation.hasFeature
>    &&  document.implementation.hasFeature("Events", "3.0")
>    &&  document.implementation.hasFeature("Events.textInput");
>
> Not very concise.

That's a bit of a reductio ad absurdum. 'hasFeature()' should be 
supported in any modern DOM implementation.  Pragmatically, you can 
simply assume the multiple levels of abstraction and make this call:

  var HAS_TEXTINPUT_EVENT = 
document.implementation.hasFeature("Events.textinput", "3.0");

or even (assuming 'textinput' doesn't change significantly in the next 
decade, which I think is a safe bet):

  var HAS_TEXTINPUT_EVENT = 
document.implementation.hasFeature("Events.textinput", "");


> Do you have a URL for the discussion that led up to that change? TIA.

No, I'm afraid I don't.  I've discussed this with a number of people 
over many years, in many groups.  If you are sufficiently curious, you 
could look back into the archives of this list (back to when 
'hasFeature()' was first defined), and in the www-svg mailing lists, 
particularly in the telcon minutes; however, scribing being the chore it 
is, I can't guarantee that it will be clear from the context when and 
where this idea developed or was refined.


> The feature, as it is written, doesn't give information for specific
> objects. It will continue to be a problem for any new event.

Any specification which defines an event should follow the mechanism 
defined in DOM3 Events for composing feature strings for the new event.


You've made your dislike of this feature detection mechanism clear, and 
I'm not claiming that it's ideal.  However, it does build upon features 
which are already implemented and well-understood, and has minimal 
implementation cost (just the addition of some feature strings which are 
compositional, so they don't even need to be stored as strings, per se). 
  I have not seen any proposals for alternate feature detection 
mechanisms that had any consensus, nor which were without faults. 
Voltaire's "the perfect is the enemy of the good" seems like a good (if 
not perfect) principle to follow here.

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

Received on Friday, 24 December 2010 03:38:05 UTC