-
Notifications
You must be signed in to change notification settings - Fork 58
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
permissions API #45
Comments
Started an empty doc at https://github.com/diracdeltas/spec-reviews/blob/review/permissions/2015/03/permissions.md. first impressionsThis document describes a simple API to allow web applications to see the current status of user-grantable permissions. I like that it addresses a very specific goal, although others brought up concerns about extensibility. The "Scope" section (3) could be more clear about this. It says, "The API specified in this document is meant to provide the tools so that web applications can improve their user experience when permissions are involved." This seems to be more broad than what the spec actually specifies. I'm not sure I understand the "Permission Registry" section (4). Who decides what is in the registry? How does a new permission get added? Are the contents of the registry public? The promises-based interface seems very nice! |
Agree the promises API is nice. I'm worried it doesn't include the ability to request permissions, has some funky API style (non-constructable types, etc.), and I share the concerns about the registry. In particular, why are many of the existing web permissions missing? How will this get evolved over time, given that we don't want WGs to stay open past their sell-by date? |
One thing I like in current spec is ternary permission status: granted, rejected, try asking user. Of course, 'prompt' is awful decision; it should be like 'wait for click and then try'. I certainly dislike situation when application should somehow catch user click to ask something. It just deteriorates user experience. For example, such situation already exists in OAuth-powered webapps: you need to wait for click to open new window to get token even if user already authorized the application. So, in my opinion, there should be some programmatical interface to know whether webapp should wait for click to ask permission or it may just ask it without direct user action. This sort of interface will certainly make UIs better. Instead of drawing large button like ‘Click me to display your location on map’ webapp will be able to render map immediately or show warning ‘Cannot display your location because you rejected to grant that permission to me’. |
There two interfaces in the spec are
My diagnosis of this is that we should want WGs to stay open indefinitely, so that there is always someone to update a spec. Publishing to TR/ and closing down is pretty terrible IMHO, e.g. if I found a problem with http://www.w3.org/TR/media-frags/ today there would be a lot of overhead in getting it fixed. (Friction in getting specs updated also leads to monkey patching.) |
Discussed in SF; consensus on Alex's feedback. |
draft: https://w3c.github.io/permissions/
TAG meeting minutes where this was discussed: https://pad.w3ctag.org/p/03-05-permissions-minutes.md
assigned to myself and @slightlyoff
The text was updated successfully, but these errors were encountered: