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

I don't care so much about performance here (we don't do feature detection that allocates non-trivial memory to avoid death by a thousand cuts, and we never throw exceptions in feature detection, so that page loads with "break on caught exceptions" don't break on non-exceptions). To directly address the request for "data". Of course, the individual detection doesn't take long, but larger apps need to detect many features. Altogether this can easily take dozens of milliseconds, which is completely unacceptable.

It is just that feature detecting this is just plain ridiculous: Imagine you teach a class about events, and the first thing people have to learn is: This is how you observe whether a property has been read in JavaScript. You can literally write GMail without knowing about that JavaScript feature if it wasn't needed for feature detecting whether event listeners support the passive option.

Meanwhile we have have global objects like `PerformancePaintTiming` that serve zero purpose, but they do allow inferring that `PerformanceObserver` will emit `'first-contentful-paint'` entries. That is great. `relList.supports` is another good example where developer ergonomics where considered in API design.

No feature on the web platform should be launched without making it detectable whether it is support in some reasonable fashion.


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