-
Notifications
You must be signed in to change notification settings - Fork 6
Description
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?