Re: [whatwg/dom] Simple EventListenerOptions feature detection (#491)

I strongly agree with @cramforce that this nasty trick for detecting whether a key is supported is *not* reasonable.  It's very complex, using a corner of JS that there's virtually no reason to go into for 99% of JS users, and it relies on there being a way to call the API that has no side-effects, which is *not* something we can depend on all such APIs having in the future.  (For example, finding if a new requestFullscreen() option is supported would... request fullscreening. That's not acceptable.)

This is terrible and untenable. It really does need to be fixed.

Again, we get 95% of the way to a solution (which is quite good enough here, people can do more complicated things for more complicated cases) *solely* by exposing the set of names supported in a particular dictionary.  This is how the majority of existing feature detection works already - just checking if a given property exists on an interface - and it's totally fine; false positive rate is fairly low, as browses are incentivized to *not* expose broken/incomplete versions of APIs, because people immediately and loudly complain about it breaking their feature detection. ^_^

I support ELO doing a one-off solution for now, and us continuing to pursue a generic solution here for exposing the set of names.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/dom/issues/491#issuecomment-322270999

Received on Monday, 14 August 2017 18:33:44 UTC