Skip to content
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

Open
tidoust opened this issue Mar 8, 2022 · 1 comment
Open

Relationship to Permissions Policy #27

tidoust opened this issue Mar 8, 2022 · 1 comment

Comments

@tidoust
Copy link
Member

tidoust commented Mar 8, 2022

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:

We considered having autoplay as a permission. However, there are a few differences between the autoplay and permissions:

  • Autoplay is something that is applied to the site from the browser; rather than something that should be requested
  • Autoplay has multiple states (e.g. allowed, allowed-muted); rather than a yes or no
  • Autoplay is not implemented by the user agents as a permission
  • Permissions are async

Is that still accurate? Could it be useful to clarify that in some informative section?

@alastor0325
Copy link
Collaborator

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 disallowed but a element has allowed. That is more complicated than the scenario designed for the Permission Policy.

Last concern is minor, which is the result of policy can be more than enabled/disabled. That could be addressed by providing different policies in Permission Policy API, eg. allow=autoplay and allow=autoplay-muted. But even if we expose different policies, we would still need to handle the scope issue mentioned above.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants