Re: Fwd: DOM event detection

On 12/28/10, Jacob Rossi <jrossi@microsoft.com> wrote:
>> How does that work? Post up some examples. Thanks.
> //Test for textinput
> var evt = document.createEvent("TextEvent");

That can throw. Needs to be in a try/catch.

> evt.initTextEvent("textinput",true,true,window,"x",1,"en-US");
> var SUPPORTS_TEXTEVENT = false
> document.addEventListener("textinput",function(e){if(e.inputMode){SUPPORTS_TEXTEVENT
> = true;}},false);
> document.dispatchEvent(evt);
> alert(SUPPORTS_TEXTEVENT?'pass':'fail');
>
Use `typeof`. What happens when inputMode is 0? Well, that's converted
to `false`..

| if(typeof e.inputMode == "number")

That approach looks like it could work for TextEvent detection.

> Though this really just tests that the event interface is supported (and an
> incomplete test at that). It doesn't make guarantees about when/if the event
> will be fired and on what eventTargets.
>
Yep. No telling if there is a supported UIEvent.

var SUPPORTS_ANYTHING = false;
(function() {
  document.addEventListener("anything", function() {
   SUPPORTS_ANYTHING  = true;
   alert("browser supports anything: " + SUPPORTS_ANYTHING);
  }, false);

  var anyEvent = document.createEvent("UIEvents");
  anyEvent.initEvent("anything", false, false);
  document.dispatchEvent(anyEvent);
})();

>> And hasFeature will continue to suffer the same bugs as can be expected.
> ...
>> Sure I do: eventTarget.generatesEvent(type).
>
> If I remember your previous thread about this, I think you're looking for
> something that indicates a particular event target fires a particular event
> type (and I recognize that my above code does not solve that).
>
> I understand why you find this valuable in theory. However, your solution is
> still decoupled from the underlying implementation.

generatesEvent would be a method of an EventTarget. It would do
introspection to determine if the target object fires an event by that
name. The method acts right on the object itself.

The implementation could look for an internal method for that object
(in C++ or whatever the browser's written in). So for:

div.generatesEvent("textinput");

- the implementation would look to see if there is an internal method
for firing "textinput" events at the div.

> still are making assumptions about the implementation's capabilities and are
> relying on the implementation to be reporting correctly its capabilities.

That's right.

So
> it's not really better than hasFeature which requires you to make similar
> assumptions.
>
No, hasFeature makes an unrelated inference. And AISB, inferences that
a program makes about the environment should, at best, be made as
closely to the feature that is being used.

Now hasFeature is not that. hasFeature is distanced from the object
that the program wants to know about. It tells nothing about the
eventtarget, per se, but about the `document.implementation` object.

If the program determines something about a `document.implementation`
object, that doesn't tell the details about a specific object.

With `hasFeature`, the browser must keep in sync the results from
`document.implementation.hasFeature` with the objects that implement
that feature.  Whereas with obj.generatesEvent, there is a check on
the object itself.

hasFeature is a design of unrelated inference. generatesEvent derives
an inference releated to a specific object.

[snip prev msg]
-- 
Garrett

Received on Tuesday, 28 December 2010 20:33:42 UTC