You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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?
The text was updated successfully, but these errors were encountered:
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.
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: