Re: [w3c/permissions] Missing introduction (#274)

The intro is not required, but it would be nice. I think it would be amazing if the intro covered the following things. Bonus would be for us to slap together a diagram. Something like Chrome's (without the usage data):

![Screen Shot 2021-08-31 at 11 46 31 am](https://user-images.githubusercontent.com/870154/131428297-8e98ed00-f1f6-4763-a598-c68cb92323a9.png)
 
And something that show and actual prompt associated with a powerful feature:

![Screen Shot 2021-08-31 at 11 50 39 am](https://user-images.githubusercontent.com/870154/131428638-2e49cdab-89fb-4334-aa1a-975f998a9365.png) ![Screen Shot 2021-08-31 at 11 53 13 am](https://user-images.githubusercontent.com/870154/131428845-96b83263-37c3-4127-8c67-804ad8715758.png)

General model: 
 * Some, but not all, specs can identify themselves as a powerful feature. 
 * Powerful features are web platform features/APIs that require user consent before they can be used. Consent its generally mediated (or gotten) via browser UI. 
 * A permissions thus captures the state of user consent to use a particular feature.
 * Users (or the user agent on their behalf) retain control of the permission, and may deny access to a powerful feature at any time, for any reason. 
 * Further, user agents can limit how long a permission grant last for (e.g., until the user closes the tab, for 1 day, for a week, forever). It's generally up to the user agent.

For specs:
  * Common infrastructure for requesting permission, prompting, etc.  
  
Developer angle:
 * Some powerful features lack a means to check the permission state. 
 * This API provides a way to query a permission's state, without interrupting the user by showing them a prompt. 
 * It also allows developers to monitor for state changes to permissions, via DOM events on `PermissionStatus`.

 

-- 
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/274#issuecomment-908833065