Re: [w3c/permissions] Add 'screen-wake-lock' permission (#247)

> I think that the idea we might want controls later, as @reillyeon says, is a good general principle to apply. If every browser implements the feature AND doesn't use the capability in any way to deny access then we can talk about removing the cruft. For now, however, it probably makes sense to leave it in.
> 
> There is no substantial harm if `.query("blah")` always returns true, for any value of "blah". Identifiers are cheap.
> 
> I've also got this vague idea that we might want to have some sort of allowance in the API for heuristic-based grants, particularly those that are granted based on user interaction (which might result in a time-limited grant).
> 
> This might be one of those where a browser might want to engage some sort of notification in their UI that the feature is enabled (like fullscreen). In that case, to ensure that the UI gets a chance to be seen, the action might only be permitted in response to user interaction.
> 
> (Maybe that's not in scope for this repo, but I thought it worth flagging.)

The idea I've been thinking about is that if the UA displayed a notification that the site is keeping the screen on that could include a button which denied the permission, so we need some spec text describing what happens when the permission is denied. 

> Anne's point about permissions policy seems like a better reason to keep the permission if you don't like mine :)

Mirroring @rakuco's comments, I think that despite the similarity in names Permissions and Permissions Policy use an entirely separate set of identifiers. The specification already has a [Policy Control](https://w3c.github.io/screen-wake-lock/#policy-control) section which completely defines the integration with Permissions Policy.

-- 
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/pull/247#issuecomment-867844754