- From: Jonas Sicking <notifications@github.com>
- Date: Fri, 08 May 2015 01:28:32 -0700
- To: w3c/permissions <permissions@noreply.github.com>
- Message-ID: <w3c/permissions/issues/25/100151862@github.com>
What I'm saying is that in the initial state, `Notification.requestPermission()` (or whatever syntax we'll use for the equivalent functionality) prompts the user. Hence returning `prompt` for `navigator.permissions.query({name:'notifications'})` seems like a good descriptive answer of how the `Notification.requestPermission()` (or whatever syntax we'll use for the equivalent functionality) behaves in its default state. Likewise when `navigator.permissions.query({name:'notifications'})` returns `granted`, `Notification.requestPermission()` (or whatever) would return `granted` without prompting the user. And when `navigator.permissions.query({name:'notifications'})` returns `denied`, `Notification.requestPermission()` would return `denied` without prompting the user. In short, returning `prompt` seems like a better description than `default` for `navigator.permissions.query({name:'notifications'})` when it comes to how the `Navigator.requestPermission()` part of the notification API behaves. I do agree that `navigator.permissions.query({name:'notifications'})` returning `prompt` is a less good description of how the `showNotification()` part of the notification API behaves, since in that state `showNotification()` would fail rather than prompt the user. But as mentioned above, I don't think that returning `default` is a particularly good description either, since the behavior is actually more like `denied`. So either way it seems like we'll need to make it clear to developers through documentation how `showNotification()` behaves for the various return values from `navigator.permissions.query({name:'notifications'})`. So all in all it seems like more gain and less loss to use `prompt` (or `ask`) rather than `default`. --- Reply to this email directly or view it on GitHub: https://github.com/w3c/permissions/issues/25#issuecomment-100151862
Received on Friday, 8 May 2015 08:29:01 UTC