-
Notifications
You must be signed in to change notification settings - Fork 8
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Web Media F2F] Document Level API issue #7
Comments
Sorry for the delay, here are a few questions, and some amendments:
after:
by something like:
another point, along the lines of:
Specifically, those two last points reference the priority of consituencies, which clearly states that things that are better for the end user (second point, faster time to playback) of the author (first point, reading an attribute is always simpler than chaining a promise) take precedence over the difficulty of implementation (or the difficulty to spec things, which does not really apply for us here). |
Like Paul, I thought we agreed that:
|
Okay thanks! I have made these adjustments in the issue description |
Historically, sites could detect whether they can autoplay by calling play and then immediately checking paused e.g video.play();
if (!video.paused) {
// we have autoplay
} Now with the play promise sites can check whether autoplay is enabled if the play promise is rejected with video.play().then(
() => // autoplay,
(e) => {
if (e.name == 'NotAllowedError')
// autoplay blocked
}); We believe having the async API here for autoplay detection would bolster the play promise and move away from a synchronous model. In addition, this has also caused us performance issues because we have to load in memory all the sites that can autoplay to know this when a page is navigated to. |
This begs the question. A sync API would have the same benefits, and it's not evident that moving away from a synchronous model is useful for web developers.
That Chrome has chosen to implement an API in a way that causes performance problems in Chrome is not a valid reason to impose a design decision on that API. The priority of constituencies places costs to page authors over costs to UA implementors. |
For developers, the difference between the sync API and the async one is the matter of an additional
It is not necessarily up to how we have implemented it but what it is doing. If we were showing a permission prompt then it would make a sync API nearly impossible but the answer should not be "well then don't do that". The API does not define what a browser should do so we shouldn't limit that. |
That requires developers who were not already using async functions to adopt them. It is arguably not a large cost, but it is a cost.
If a permissions prompt was necessary, there would be a |
Close this issue because we had already decided to use sync API by previous all discussions. |
We had a Web Media F2F meeting with Apple, Google, Microsoft and Mozilla attending. We discussed this API and this issue is a follow up from that.
The document has an autoplay policy which can change. There will be an API on the document to get the autoplay policy and another on the media element which will return a boolean as to whether the media will be able to autoplay.
There are four types of autoplay policy:
allowed
- autoplay is allowedallowed-muted
- muted autoplay is alloweddisallowed
- autoplay is not allowedunknown
- document level autoplay is unknown, so we should use the API on the media element insteadThere were two different options for the document level API which are described below:
Option 1: Sync API
The first option is for a completely synchronous API.
AutoplayPolicy
here is an enum of the different policies defined above.Pros:
Cons:
Option 2: Promise API
The second option is for a promise based API.
AutoplayPolicy
here is an enum of the different policies defined above.Pros:
getAutoplayPolicy
is calledCons:
--
It was decided at the meeting to ask TAG for their opinion on which option would be suitable.
The text was updated successfully, but these errors were encountered: