Skip to content
This repository has been archived by the owner. It is now read-only.

Better feature detection: getSupportedListenerOptions is weird #16

Closed
smaug---- opened this issue Jul 8, 2015 · 8 comments
Closed

Better feature detection: getSupportedListenerOptions is weird #16

smaug---- opened this issue Jul 8, 2015 · 8 comments
Labels

Comments

@smaug----
Copy link
Collaborator

@smaug---- smaug---- commented Jul 8, 2015

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
Copy link
Member

@RByers RByers commented Jul 8, 2015

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----
Copy link
Collaborator Author

@smaug---- smaug---- commented Jul 8, 2015

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
Copy link
Member

@RByers RByers commented Jul 8, 2015

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 RByers added the spec label Jul 8, 2015
@RByers
Copy link
Member

@RByers RByers commented Jul 9, 2015

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

@bzbarsky
Copy link
Collaborator

@bzbarsky bzbarsky commented Jul 9, 2015

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
Copy link
Member

@RByers RByers commented Jul 9, 2015

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

@RByers RByers changed the title getSupportedListenerOptions is something very unique in the platform Better feature detection: getSupportedListenerOptions is weird Jul 9, 2015
RByers added a commit that referenced this issue Jul 9, 2015
@dtapuska
Copy link
Collaborator

@dtapuska dtapuska commented Jul 9, 2015

@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
Copy link
Collaborator

@bzbarsky bzbarsky commented Jul 9, 2015

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

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
4 participants
You can’t perform that action at this time.