-
Notifications
You must be signed in to change notification settings - Fork 2
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
Questions about permissions #28
Comments
I'm vehemently opposed to adding permissions to this proposal. As you mention, nothing groundbreaking (functionality-wise) is being done here -- this "simply" addresses a) the non-standard routes developers need to go in order to support this and b) the less than optimal mechanisms in which developers have to trigger this. If a a permission system were added on top, I feel that developers would be quite unlikely to adopt this over already existing solutions as those solutions offer a far better DX. The ideal, for me, is to get developers to start relying on media queries over custom Until browsers have ways to force user preferences upon web content, wanting to permission-gate changing preferences seems to indicate a lack of understanding as to the modern web. |
I think different settings/overrides require different permission strategies. Overrides go above what's currently possible by just ignoring the media query, as they disable browser behaviors such as disabling some animations and sending headers. While some overrides such as dark theme are probably less worrying and could get away with just a UA notification that the setting was changed by the site, disabling accessibility features (e.g. reduced motion) or money-saving features (e.g. reduced data) are different beasts entirely. My preference is that a general permission is added in case a website wants a blanket right to change all settings without UA involvement, but otherwise it should be possible to call the API without the permission and it's then up to the UAs to decide which level of involvement they want to have (e.g. just a notification of change for dark theme, but confirmation dialog for reduced motion). |
Right I think for now I'll remove the permissions checks from the algorithm and replace it with a UA defined algorithm. So it's down to the UA to decide what to do. I'm thinking if we do want a permission to say give me free reign we potentially need a new |
For now simply allow a UA defined algorithm for allowing a request. This can include a permission prompt or any other mechanism the UA sees fit. Related to #28
I already exclude the "custom" value from the The case for enabling these options feels a lot stronger than the case for disabling them? #30 to discuss this |
To update this, I've removed the ability to set a "no-preference" override. So I think the case for permissions is strongly diminished as a result. The API shape is a promise such that it can be adjusted to the UAs desire. I'll leave this issue open for now in case anyone else wants to chime in. |
I've added an integration with the permissions API and required a permission is granted before being able to requestOverride. This was in response to feedback in #27 (comment) aswell as just being a general attempt at mitigating concerns about this API.I've subsequently reverted the permission integration and replaced it with a UA defined algorithm so it's up to the UA to decide if they want a permission prompt etc.However I am worried this will put a lot of people off using the API, permission prompts are pretty "scary" things and in this case provides little actual benefit imo.
This API doesn't really introduce any new dangerous (or otherwise) capabilities beyond that which are already possible. Aside from the very core capabilities this seeks to resolve.
The text was updated successfully, but these errors were encountered: