{"action":"created","issue":{"url":"https://api.github.com/repos/WICG/EventListenerOptions/issues/27","repository_url":"https://api.github.com/repos/WICG/EventListenerOptions","labels_url":"https://api.github.com/repos/WICG/EventListenerOptions/issues/27/labels{/name}","comments_url":"https://api.github.com/repos/WICG/EventListenerOptions/issues/27/comments","events_url":"https://api.github.com/repos/WICG/EventListenerOptions/issues/27/events","html_url":"https://github.com/WICG/EventListenerOptions/issues/27","id":146086522,"number":27,"title":"Should the passive option be part of the event listener key","user":{"login":"RByers","id":1280419,"avatar_url":"https://avatars.githubusercontent.com/u/1280419?v=3","gravatar_id":"","url":"https://api.github.com/users/RByers","html_url":"https://github.com/RByers","followers_url":"https://api.github.com/users/RByers/followers","following_url":"https://api.github.com/users/RByers/following{/other_user}","gists_url":"https://api.github.com/users/RByers/gists{/gist_id}","starred_url":"https://api.github.com/users/RByers/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/RByers/subscriptions","organizations_url":"https://api.github.com/users/RByers/orgs","repos_url":"https://api.github.com/users/RByers/repos","events_url":"https://api.github.com/users/RByers/events{/privacy}","received_events_url":"https://api.github.com/users/RByers/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"milestone":null,"comments":23,"created_at":"2016-04-05T19:25:23Z","updated_at":"2016-04-14T17:25:36Z","closed_at":null,"body":"At the moment, the following code installs two listeners (`handler` will get invoked twice):\r\n\r\n```javascript\r\n  target.addEventListener(type, handler);\r\n  target.addEventListener(type, handler, {passive: true});\r\n```\r\n\r\n@annevk points out this may not make sense - it may be better to treat them as the same.\r\n\r\nIf we want to change this, we have to define what the second call does.  Is it just ignored?  Or maybe a listener can be \"upgraded\" from `passive` to blocking but not the other way around?\r\n\r\nI was really just following the precedent set by `capture` here - no real argument one way or the other.  Can anyone shed light into why `capture` behaves this way?  That seems odd / useless also.\r\n\r\nIs there a good reason we'd want `capture` to have different semantics than `passive` (and presumably new options)?  Maybe `capture` can just be forever odd for legacy compat reasons?\r\n\r\nThis is an edge case I think is unlikely to affect any real code, so I think the compat risk of changing this is minimal.\r\n"},"comment":{"url":"https://api.github.com/repos/WICG/EventListenerOptions/issues/comments/210062323","html_url":"https://github.com/WICG/EventListenerOptions/issues/27#issuecomment-210062323","issue_url":"https://api.github.com/repos/WICG/EventListenerOptions/issues/27","id":210062323,"user":{"login":"RByers","id":1280419,"avatar_url":"https://avatars.githubusercontent.com/u/1280419?v=3","gravatar_id":"","url":"https://api.github.com/users/RByers","html_url":"https://github.com/RByers","followers_url":"https://api.github.com/users/RByers/followers","following_url":"https://api.github.com/users/RByers/following{/other_user}","gists_url":"https://api.github.com/users/RByers/gists{/gist_id}","starred_url":"https://api.github.com/users/RByers/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/RByers/subscriptions","organizations_url":"https://api.github.com/users/RByers/orgs","repos_url":"https://api.github.com/users/RByers/repos","events_url":"https://api.github.com/users/RByers/events{/privacy}","received_events_url":"https://api.github.com/users/RByers/received_events","type":"User","site_admin":false},"created_at":"2016-04-14T17:25:36Z","updated_at":"2016-04-14T17:25:36Z","body":"In the event delegation scenario, any such library should really be delegating separately for the passive and non-passive clients (and so installing two real listeners with different handler functions).  Eg. we wouldn't want one tiny non-passive touch listener on the page to cause an existing passive touch listener on the window to be treated as non-passive (that would be really bad for perf).  I agree it's possible that event delegation code might screw this up, but I think there's a lot of ways they could screw up in any of the options, not clear to me that either approach is substantially less error-prone.  Or maybe I don't understand completely?\r\n\r\n> One, perhaps a bit ugly option, is to throw if one tries to add existing listener with same key but different EventListenerOptions.\r\n\r\nI'd be fine with that, it also gives us the flexibility to potentially relax in the future if we deem it valuable."}}