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

Comments

Projects
None yet
4 participants
@smaug----
Collaborator

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

This comment has been minimized.

Show comment
Hide comment
@RByers

RByers Jul 8, 2015

Member

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.

Member

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

This comment has been minimized.

Show comment
Hide comment
@smaug----

smaug---- Jul 8, 2015

Collaborator

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.

Collaborator

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

This comment has been minimized.

Show comment
Hide comment
@RByers

RByers Jul 8, 2015

Member

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?

Member

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

This comment has been minimized.

Show comment
Hide comment
@RByers

RByers Jul 9, 2015

Member

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

Member

RByers commented Jul 9, 2015

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

@bzbarsky

This comment has been minimized.

Show comment
Hide comment
@bzbarsky

bzbarsky Jul 9, 2015

Collaborator

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.

Collaborator

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

This comment has been minimized.

Show comment
Hide comment
@RByers

RByers Jul 9, 2015

Member

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

Member

RByers commented Jul 9, 2015

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

@RByers RByers changed the title from getSupportedListenerOptions is something very unique in the platform to Better feature detection: getSupportedListenerOptions is weird Jul 9, 2015

RByers added a commit that referenced this issue Jul 9, 2015

@dtapuska

This comment has been minimized.

Show comment
Hide comment
@dtapuska

dtapuska Jul 9, 2015

Collaborator

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

Collaborator

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

This comment has been minimized.

Show comment
Hide comment
@bzbarsky

bzbarsky Jul 9, 2015

Collaborator

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

Collaborator

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.