Autoplay Detection API

[beccahughes]

Góðan dag TAG！

I'm requesting a TAG review of:

• Name: Autoplay Detection API
• Specification URL: https://github.com/WICG/autoplay
• Explainer, Requirements Doc, or Example code: Add proposed explainer w3c/autoplay#8
• Tests: N/A
• Primary contacts: @beccahughes @mounirlamouri @padenot @jyavenard @eric-carlson @hober @jernoble

You should also know that...

There is strong disagreement about whether this API should be async or sync.

We'd prefer the TAG provide feedback as (please select one):

• open issues in our Github repo for each point of feedback
• open a single issue in our Github repo for the entire review
• leave review feedback as a comment in this issue and @-notify [github usernames]

[dbaron]

This was discussed in yesterday's teleconference.

I think one of the conclusions is that our template for requesting TAG reviews is better suited for specifications that already have consensus within the group working on them, than for areas with active disputes. It also wasn't clear to what extent the review request was (a) a request to review one of the two alternatives (b) a request to review both alternatives, or (c) a request to weigh in on the dispute between the alternatives. If it's (c), then we'd be hesitant to weigh in without a chance to read the arguments presented by each side in that dispute... and it's not entirely clear where those are.

In addition to the sync vs. async question, I also raised a question about having a document-level API versus an element-level API if the answer is only consistent across all elements in some browsers.

[eric-carlson]

It also wasn't clear to what extent the review request was (a) a request to review one of the two alternatives (b) a request to review both alternatives, or (c) a request to weigh in on the dispute between the alternatives. If it's (c), then we'd be hesitant to weigh in without a chance to read the arguments presented by each side in that dispute... and it's not entirely clear where those are.

My understanding is (c). We discussed this at length during the F2F last month but could not agree on the autoplay policy API, so the escalation was to have the TAG evaluate the alternatives and provide guidance.

[dbaron]

If that's the case, then where should be we looking for the arguments on each side?

[beccahughes]

The pros / cons for each side are here: w3c/autoplay#7

[hadleybeeman]

Hi. We are reviewing this at our face-to-face in Reykjavik.

We understand that you've put quite a lot of time into discussing this, but it's difficult to work out some of the basics from the write-ups. It would really help us if you had an explainer.

For example, I can't tell which user's needs you want to meet here? Is it that the developer/site can detect the autoplay status of the page? If so, what the benefit to the end user is of the developer being able to detect the autoplay status? (etc) Or is it that you want the UA to know what the page's policy is? And if so, why?

It would also help us a lot if you completed the Security and Privacy questionnaire. There are most likely significant privacy concerns here, so it would help us all if you led that discussion.

If this is just a general asyc/sync question, we might have generic opinions... but I'm not sure that will do justice to what you're trying to build. If you can help us a bit more, we can be much more useful to you. Thanks!

[hober]

Hi,

In addition to Hadley's comments, we've discussed this in a number of telcons and at our spring F2F in Reykjavík.

First off, we're very sorry that it's taken so long to get back to you on this review—we are in the process of trying to refine our processes to get quicker at working through our backlog.

We're also sorry that our design review issue template was somewhat unsuited to cases like these, where the folks raising the issue have been unable to come to consensus on the technical question at hand. It was hard for us to follow this, and our template didn't guide you to link to the issue (w3c/autoplay#7) that captures the various proposals on the table. We have since made a number of changes to our template to better handle such cases. (See 7e446fa, df507f6, 9237bd6, 68a1436, and 5e02e7c.)

Since this escalation request was received, the venue of the spec in question has changed, and the venue change brings with it several relevant process changes. This spec is now a chartered deliverable of the Media WG, which operates under the W3C Process. It's the role of chairs of that WG to help find consensus on this issue among the various WG participants. The Process document also defines how the chairs should manage dissent.

Given the above, we're remanding this matter to the Media WG chairs to take up. (cc @jernoble @mounirlamouri) We hope that the venue shift to a group which operates under the W3C Process will help them, and the community who have contributed to this issue, to come to agreement.

[torgo]

Closed in favor of #439.