Autoplay Detection: async vs sync API

[mounirlamouri]

Hello TAG!

I'm requesting the TAG express an opinion on a dispute related to:

• Name: Autoplay API
• Specification URL: N/A
• Explainer (containing user needs and example code)¹: [TPAC 2018] Autoplay Policy Informal Meeting Notes w3c/autoplay#1 is closest to an explainer
• GitHub issues (if you prefer feedback filed there): N/A (feedback on this bug will be fine)
• Primary contacts (and their relationship to the specification): @beccahughes (editor) @padenot (editor), @jernoble (chair), @mounirlamouri (chair)
• The group where the work on this specification is: Media WG
• Links to major pieces of multi-stakeholder review or discussion of this specification:
  • [Web Media F2F] Document Level API issue w3c/autoplay#7
  • https://www.w3.org/2019/09/19-mediawg-minutes.html
• Links to major unresolved issues or opposition with this specification: see above and below
• Relevant time constraints or deadlines: N/A

Explanation of the issue that we'd like the TAG's opinion on:

The group is divided with regards to the interpretation of the Client-side API Design Principles,
in particular section 2.8 regarding asynchronous vs synchronous APIs when
put against the HTML Design Principles, in particular 3.2 Priority of Consistencies.

The context of the problem is fairly simple: UAs would like to expose the autoplay policy currently used by the page to allow them
to make some early decisions for their user experience The question is whether it should be exposed as document.getAutoplayPolicy()
returning a Promise<AutoplayPolicy> or document.autoplayPolicy returning AutoplayPolicy.

Links to the positions of each side in the dispute (e.g., specific github comments):

Chrome would like for the API to be asynchronous because:

• it is close enough to a permission that it was often suggested to use the Permissions API for this and Permissions are asynchronous
• Chrome's implementation of autoplay policy is much more complex than permission and today read 2 databases, 3 in the future -- being required to eagerly load these databases at browser startup because of the API shape isn't ideal
• with async, the cost of an asynchronous API is small especially given that the solutions implemented by web pages today are asynchronous in nature (load a resource)
• the delay for authors is insignificant especially compared to media loading
• the above should follow the guidelines of section 2.8 of the TAG design principles and is a good compromise for the authors with regards to 3.2 of HTML design principles.

Mozilla & Apple would like the API to be synchronous because:

• it is possible to implement the API synchronously by pre-loading the information at navigation time and send it to the page
• UAs should take the complexity in their engine to allow for an immediate answer to the web page
• the above follows the guidelines of section 3.2 of html design principles and Chrome concerns do not meet the bar for section 2.8 of the TAG design principles
• UAs (Safari, atm) that only allow playback when happening in a user gesture handler would need to carry over the gesture "flag" across the Promise boundary.

What steps have already been taken to come to an agreement:

The issue has been discussed on GitHub, during an informal offsite on the side of FOMS NYC and at TPAC. We believe that the best solution
at this point is for the TAG to clarify its design principles as this is the core of the issue. All parties would be happy to follow the
TAG recommendations.

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

• leave a comment in the following GitHub issue: [url]
• leave review feedback as a comment in this issue and @-notify [github usernames]
• open a new issue in our GitHub repo with the feedback

[torgo]

Tentatively put this down for a discussion at our next f2f (1st week of December). Please let us know if you need feedback sooner than that.

[hober]

Hi,

We looked at this issue in our Cupertino F2F. We agree that the Design Principles document needs to be updated to cover nuanced cases like these. We've filed w3ctag/design-principles#145 to track that update.

We think, in this case, the API should be synchronous, due to many factors that have already been captured in the minutes of the Media WG session at Fukuoka, and in our minutes today (which I will link here once they're posted), namely:

• An async API would unnecessarily complicate the work of web developers (and while this may enable particular implementation strategies, the Priority of Constituencies favors web developers over browser engineers),
• A sync API is more predictable and would not have timing issues (such as when you create a promise during a user gesture and resolve it outside of that gesture).

[annevk]

Hmm, but we're changing the way user gestures are done so that short-lived asynchronous work is no longer problematic. Was that taken into account?