RE: Fwd: DOM event detection

> How does that work? Post up some examples. Thanks.
//Test for textinput
var evt = document.createEvent("TextEvent");
document.addEventListener("textinput",function(e){if(e.inputMode){SUPPORTS_TEXTEVENT = true;}},false);

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.

> 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. So no matter what, you still are making assumptions about the implementation's capabilities and are relying on the implementation to be reporting correctly its capabilities. So it's not really better than hasFeature which requires you to make similar assumptions.

-----Original Message-----
From: Garrett Smith [] 
Sent: Monday, December 27, 2010 11:31 PM
To: Jacob Rossi
Subject: Re: Fwd: DOM event detection

On 12/27/10, Jacob Rossi <> wrote:
> Garrett Smith:
>> If hasFeature is to be used, it must be first feature tested.
> As will any alternate API for detecting implementation.
>>That feature [hasFeature()] cannot be reliably used for the web.
> The fact that it isn't reliable today isn't proof that it is a bad API
Nope. Old and historically unreliable feature. Nobody uses it because it doe3sn't work.

> (hence, Doug's "reductio ad absurdum" comment).

Why doesn't hasFeature work? Well you see, that's that problem right there. It's the way its designed.

> Incorrect reporting by hasFeature() by an implementation is simply a 
> bug on the implementation's part.

And hasFeature will continue to suffer the same bugs as can be expected. document.implementation is a unrleated interface.

An expectation that all implementations hasFeature updated for features that function properly will result in the type of disappointment that has led to the failings of hasFeature.

The inferences that a program makes about the environment should, at best, be made as closely to the feature that is being used. One who is less experience in the failings of unrelated inference might optimistically chock it up to bad browsers.

The first problem is that the feature is unrelated to the implementation code. The second problem is that the APIs the w3c makes are so featureful that they do not provide enough granularity.

The optimistic D3E author addresses granularity but does not address the unrelated inference problem.

> Unfortunately, any alternative to hasFeature will likely suffer from 
> implementation bugs or incomplete implementation like the examples you gave.

The unrelated inference problem can't be fixed; it is a core design of the feature testing being on an `implementation` object of a `document`.

> Unless you have a counter proposal,

Sure I do: eventTarget.generatesEvent(type). I followed up to most threads, but could not follow up on all fo those threads because I was banned for what was called a "two weeks" ban after offensive remarks about an esteemed W3C financier.

I believe the only solution which will
> be reliable on the web *today* is to create and dispatch a test event 
> yourself.
How does that work? Post up some examples. Thanks.

Received on Tuesday, 28 December 2010 15:38:53 UTC