Re: [w3c/permissions] Drop .request() (#83)

Coming back to this issue, we've talked over the pros and cons within Google a bit, and we still think `permissions.request()` is the right thing to do:

1. It will let us stop building request() functions in future interfaces. They'll still need to define their descriptors and result types, but the TAG won't have to double-check that the overall shape is right.

2. A new [polyfill](https://www.npmjs.com/package/permissions.request) shows that if folks want the request() shape today, they can get it, so the new API won't do any more to let sites ask for permissions out of context. Along with `permissions.query()`, we think it'll actually help sites ask *in context*, since it helps authors think about exactly when they're showing prompts to their users.

3. If we keep `request()`, we'd like to add guidance that new specs should avoid showing permission prompts from any function other than `permissions.request()`. To accomplish this, `permissions.request()` could always include an object in its result that would be used to access the requested API, and `request()` would probably be the only way to get that object. In the very long run, we can think about deprecating the old spellings of functions like `Notifications.requestPermission()` and `getUserMedia()` in favor of `permissions.request()`, in order to remove the redundancy, but of course we wouldn't do that until usage fell low enough.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3c/permissions/issues/83#issuecomment-242571980