Comments (6)
Possibly! Above my pay grade. I think the most important use case is met :-)
from autoplay.
Thanks @hamishwillee. I renamed the issue to focus on your points 2 and 3, having fixed the typos.
from autoplay.
Thanks @chrisn. FYI I finished the docs and I think I understand how this works now. Essentially the media type query returns the default policy for the media type on the page - this is the policy you'd get on page load before any user interaction or whatever. The page policy can change due to things like sticky activation, but the per item policy might change either temporarily due to transient activation (on firefox) or due to sticky activation that only applies to a particular element (e.g. safari).
That's why it is rough - after the user has interacted with the page the returned media type might differ for some elements even if all the others are the same. And it is also why the "must" can be wrong.
from autoplay.
I believe the rational is something like this:
- if I were to create a new media element, is it likely to be able to be autoplayed?
- I already have a video element, can it autoplay?
This is why you need to be able to query by element and by type. I agree it's rough, but I think it's still an improvement on the current state of things, which relies on testing elements a la https://github.com/video-dev/can-autoplay
from autoplay.
@gkatsev I agree it's much better and certainly meets that important first use case. Just the description of what is returned for a type check may not be correct because the page policy does not have to match the policy of individual elements. If it did, you would not need the element check.
I have doubts about the second rationale. Yes you can check if a particular existing element can autoplay but there is nothing to tell you that you need to do so. On page load you just check the type, because all elements have the same policy. Later on you want to add an element you can check the type too. However if you have an existing element and the policy for it has changed there is no notification for you that it might have changed policy. i.e. no trigger to know that it is worth checking if it can autoplay.
from autoplay.
I was thinking whether an event might be helpful, and it still might, but looks like it was previously rejected for reasonable concerns #6 (comment)
I kind of either users just "set it and forget it" and not worry about whether autoplay happens or they need to check the autoplay policy each time before doing anything related to autoplay.
However, it might be worth figuring out whether it's possible for an allowed
policy to transition to allowed-muted
or disallowed
, at least for a specific video element? I'd have to defer to browser vendors for that, but if that is a valid constraint, it would definitely help teach this feature to users.
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
- Preventing sites from prompting users on Autoplay HOT 4
- 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
- Relation to prefers-reduced-motion HOT 2
- Spec should document fingerprinting and XSLeak risk
- notifying the site of a browser intervention can be user harming HOT 1
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.