Better feature detection: getSupportedListenerOptions is weird

[smaug----]

There are plenty of APIs taking a dictionary as a param, yet I don't recall anything like getSupportedListenerOptions(). Do we really need it?

[RByers]

Yeah I wasn't sure how best to handle feature detection (#8). If we go with your idea of a backwards-compatible hint (eg. #12) then perhaps we can get away without feature detection so maybe we need to resolve the debate in #2 before worrying about this.

But even if we go with a backwards compatible "hint", might there still not be scenarios where a library wants to know whether the hint is supported? Eg. maybe if it knows performance will be improved it'll disable some minor feature in order to be able to take advantage of non-cancelable touch events. But maybe that's too minor of a reason to justify.

[smaug----]

I think before exposing getSupportedListenerOptions() to the platform this needs some more generic discussion whether we want to expose possible dictionary properties and their default values - not only in this API but in APIs in general.

[RByers]

Sounds like a good idea. Let's try to resolve the debate in #2 first. Then if we still need some form of feature detection I can start this discussion. What do you think is the appropriate forum?

[RByers]

@foolip suggests (on whatwg list) putting getSupportedListenerOptions this on EventTarget instead of Event.

[bzbarsky]

For just feature detection, you can use an object with getters on it. That won't tell you the default values of the dictionary properties; just which dictionary properties are supported by the browser.

[RByers]

Oooh, cool - thank you! I'm sold.

[dtapuska]

@bzbarsky Doesn't this rely on the implementation detail that they will be queried when addEventListener executes. Some implementations might wait until a property is queried or dispatchEvent to execute no? (I'm not sure on the details of the other implementations)

[bzbarsky]

@dtapuska The dictionary properties must be queried before the spec algorithm of addEventListener executes. That's not an implementation detail; it's a basic Web IDL spec requirement. The timing is fully specified, the order in which the getters are executed is fully specified. Has to be that way, since getters can have arbitrary side-effects so you have to pin down the behavior completely to get anything resembling interop.