Skip to content

Relationship to Permissions Policy #27

@tidoust

Description

@tidoust

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?

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions