Comments (4)
require users to turn off auto play to continue browsing?
I suppose you mean "turn off blocking autoplay"?
Not sure I understand this quesition correctly. No matter we have Autoplay Detection API or not, websites can always ask users to turn off blocking autoplay if they really want to make their media playing. (because they can know that by the rejected promise)
Autoplay Detection API is used to give websites a better way to know whether media can be allowed to autoplay, in order to let them have a chance to implement something which has a better user experience, instead of showing still images or nothing.
If prompting to users is because website can't detect autoplay policy well, then I think this API is defintely helpful for preventing showing more prompts. But if prompting to user is just because websites really want everything on their site playable, then that would be website's choice and we can do nothing.
from autoplay.
Yes, I meant - "turn off blocking autoplay".
Are there examples of sites that would like to detect autoplay being blocked and switch to different media? All the feedback we have received so far are about how autoplay limit is not comprehensive enough and that users want a stricter ability to prevent autoplay and more control (restricting gifs for example).
The current proposal moves the balance more towards the site, and restricts future UAs from doing things like delaying the resolution of the play promise until the user consents to it - since the policy is exposed upfront and sites may change their behavior based on the response.
Perhaps the strategy with this proposal is to work with web developers and if they had a way to detect user preference, they would not auto play media. I would like to learn more about this aspect, are there public asks that I could look at.
from autoplay.
Minutes from Media WG discussion on 8 March 2022: https://www.w3.org/2022/03/08-mediawg-minutes.html#t01
If the result from calling the API is only informative, does this impact how sites want to adapt based on browser auto-play policy?
I suggest seeking developer input on this, for example via the video-dev slack group.
from autoplay.
Reading the minutes, I do not think that making this API non-binding is useful and will potentially lead websites to ignore the API altogether and continue with detecting the autoplay behavior by trying to play a video element like the can-autoplay module does.
Specifically, a big issue is around ads. Ads that are played with audio vs muted ads come from different inventories and have different costs associated with them, so, it's important to know ahead of time what the autoplay policy is. In these cases, the appropriate ad that corresponds the autoplay detection will then be loaded. For example, ads that are allowed to play muted or ads that are with audio when autoplay isn't allowed altogether.
In addition, player libraries that provide simplified tooling around autoplay will not be able to simplify their code either. For example, in Video.js, we have autoplay enums like muted
, and any
which specify autoplay behavior for the player. With any
the player will try to play with sound and then if the promise fails, mute the player and try again, and if it fails again, fall back to click to play. With the new autoplay policy API, it should theoretically be possible to simplify this code and go directly to the correct interaction based on the policy, but if it isn't binding, we can't rely on it and have to maintain the code we have currently.
from autoplay.
Related Issues (20)
- CFC: Issues #3, #6, and #7 - sync vs. async HOT 11
- The final decision of autoplay detection API name HOT 60
- Media autoplay permission HOT 25
- Alternate API design HOT 18
- Throw an exception when authors pass an unsupported constructor or element to `getAutoplayPolicy()`
- Need to adjust IDL to make overload definitions distinguishable? HOT 2
- Privacy, Spec should call out that the API discloses user settings that is a fingerprinting vector. HOT 3
- The API restricts autoplay options to current status quo HOT 5
- Publish FPWD HOT 1
- Relationship to Permissions Policy HOT 1
- Split security and privacy considerations HOT 1
- FPWD Horizontal reviews
- Autoplay Policy Detection API i18n self-review HOT 4
- Autoplay Policy Detection API accessibility self-review HOT 1
- Declarative Autoplay Policy Detection
- Only use exceptions/promise rejections for exceptional situations HOT 5
- readonly attribute Promise<AutoplayPolicy> autoplayPolicy; HOT 32
- [Web Media F2F] Document Level API issue HOT 8
- Intent to Migrate: Autoplay Policy Detection HOT 3
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from autoplay.