-
Notifications
You must be signed in to change notification settings - Fork 7
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
Relationship to Permissions Policy #27
Comments
Permissions Policy provides a way to enable/disable certain feature, and Autoplay Policy Detection provides ways to help developers understand what the status of the autoplay feature is. As we don't let Permissions Policy to operate autoplay feature, they don't have any relationship at all. So the question would be "if Permission Policy API should support setting autoplay feature"? tl;dr From my opinion, it could, but maybe non-necessary. The Following lists some concerns and difficulties. Currently determining if a media is allowed to autoplay works very differently among each user agent, most of them are not requiring users to approve/deny the request directly. (Although Edge mentioned they might try to prompt users. Firefox also tried to do that before but we decided not to go that way) Therefore, it doesn't fit the definition of powerful features at least for most user agents nowadays. Another concern which is already mentioned in the comment1 is the scope of autoplay. Permissions Policy can only define a policy on a document, but Autoplay Policy can be either on a document, a element (a media element or an audio context). And the document can event have a different policy result from a element. Eg. document has Last concern is minor, which is the result of policy can be more than |
Via w3c/transitions#418 (comment) where @plehegar writes: "I'm surprised that this document doesn't use or mention https://www.w3.org/TR/permissions-policy/ . Is there a reason why this spec is not more integrated?"
The Permissions Policy spec is grounded on the notion of policy controlled feature, which is "an API or behaviour which can be enabled or disabled in a document" (by web developers typically). That does not fully map to autoplay because there is no requirement that the autoplay policy can be enabled or disabled. Plus the autoplay policy may be per element rather than per document, and the autoplay policy may return more than "enabled" and "disabled" (through "allowed-muted", also see discussion in #25).
The Permissions spec is grounded on the notion of powerful feature, which is "a web platform feature (usually an API) for which a user gives express permission before the feature can be used". That does not fully map to autoplay either because there is no requirement until now that the autoplay policy be based on the user giving express permission.
The explainer document that was discussed in PR #8 detailed similar reasoning:
Is that still accurate? Could it be useful to clarify that in some informative section?
The text was updated successfully, but these errors were encountered: