- From: Tab Atkins Jr. <notifications@github.com>
- Date: Mon, 14 Aug 2017 11:32:05 -0700
- To: whatwg/dom <dom@noreply.github.com>
- Cc: Subscribed <subscribed@noreply.github.com>
- Message-ID: <whatwg/dom/issues/491/322270999@github.com>
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