Re: Fwd: DOM event detection

On 12/23/10, Doug Schepers <> wrote:
> Hi, Garrett-
> Garrett Smith wrote (on 12/23/10 9:39 PM):
>> On 12/22/10, Doug Schepers<>  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

Too optimistic. The feature needs proof that it works. I believe there
is enough evidence in this and even more in "can dispatch can
dispatch" thread, to show that the feature should not be relied upon
for the web.

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

If hasFeature is to be used, it must be first feature tested. You
actually implied so yourself; I was just writing out in code what
you'd written. That is:

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

And I applied "in a conforming DOM3 Events UA" to the code. Page
author's don't get to decide the user's choice of browser.

hasFeature()' should be
> supported in any modern DOM implementation.  Pragmatically, you can
> simply assume the multiple levels of abstraction and make this call:

That feature cannot be reliably used for the web.

> document.implementation.hasFeature("Events.textinput", "3.0");
That won't work generally for all event types. If we try the `input`
event in Safari 5 on Windows, it results `false` in Safari:

 alert(document.implementation.hasFeature("Events.input", "3.0"));

Results false, yet:

var a = document.createElement("input");
 a.setAttribute("oninput", ";");

"function oninput(event) { ;

And the event type there seems to be supported.

MOre over, the problem here is that the D3E is in a draft, and so no
implementation should be expected to return true at this point,
because hat if the draft changes? Well then if the draft changes, then
a `true` result for hasFeature might have a slightly different meaning
in the new draft, for a specific event.

> or even (assuming 'textinput' doesn't change significantly in the next
> decade, which I think is a safe bet):
> 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.
How much money do you want to bet that specific feature strings will
not fall out of sync in a major implementation, within the first year
of D3E being an official TR?

The hasFeature is removed from the actual feature of dispatching the
event. It is not part of the object the developer cares about, but is
a property of a document.implementation object -- a totally separate

> You've made your dislike of this feature detection mechanism clear,

My personal likes and dislikes aren't really relevant to this thread*.
And I'm taking a fair stance on both the practical implications for
the OP, and for future considerations.

The feature deserves a closer look.

I do not have much time to help with this. I hope that other
developers will volunteer their time to see this through.
* personal:
 twitter xkit
 youtube: dhtmlkitchen

Received on Friday, 24 December 2010 04:50:04 UTC