Should we align permissionState values with other APIs? #80
Comments
|
To reverse this, is there any good reason NOT to change it? What was the rationale for making it |
|
Please use Notifications is the outlier here, but it's rather difficult to change the value given that multiple implementations shipped it already. Newer APIs have settled on |
|
+1 to converge on prompt (I don't remember seeing a rationale for default). |
|
+1 to converge to default; I wish the Permissions API didn't fork the existing shipping APIs with its new name for things. |
|
@domenic -- to be clear, your +1 is a dissenting opinion, right? To keep it as-is rather than align with Permissions? |
|
@clelland yeah, as well as a vote for fixing Permissions. grumble grumble. |
|
I also dislike the Permissions API forking precedent. |
|
The one-shot spec has no permission status method. I suggest for one-shots that we keep it that way and if we need permission in the future we can use the Permissions API for it. |
In #39, we've discussed the merits of sharing method names for the {get|has}Permission(Stat{e|us}?) method with the Push, Notification, and Permissions APIs.
Should we also be aligning the enum values values with those APIs? Push and Permissions both use
granted,denied, andprompt, while Notifications and BackgroundSync havedefault,denied, andgranted.If we're eventually moving to the Permissions API, then maybe we should be using it's enums. I think that '
prompt' is useful to have, and makes more sense thandefaultfor BackgroundSync. ('default' is a nebulous concept anyway, and if the user agent reserves the right to change what the default behaviour is, then it doesn't tell the app developer anything at all. 'prompt' is at least explicit about what will happen.)The text was updated successfully, but these errors were encountered: