[w3ctag/design-reviews] Autoplay Detection: async vs sync API (#439)

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)¹: https://github.com/w3c/autoplay/issues/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:
     - https://github.com/w3c/autoplay/issues/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](https://w3ctag.github.io/design-principles/),
in particular [section 2.8](https://w3ctag.github.io/design-principles/#promises) regarding asynchronous vs synchronous APIs when
put against the [HTML Design Principles](https://www.w3.org/TR/html-design-principles/), in particular [3.2 Priority of Consistencies](https://www.w3.org/TR/html-design-principles/#priority-of-constituencies).

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 synchrounous 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]
  - [X] leave review feedback as a comment in this issue and @-notify [github usernames]
  - [ ] open a new issue in our GitHub repo with the feedback

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/439