Query by a Media Type feels inconsistent

[hamishwillee]

1. Need to run a general spell check. In "W3C Working Draft, 15 September 2022", there are three (incorrect) instances of "asscociated"

2. Doc in 2.2.1. Query by a Media Type feel's inconsistent.

   • getAutoplayPolicy(type) methods return the rough status - so it's like "probably this is the status for all elements, but if you really care you need to check".

   • But below it uses the word "MUST"

     When getAutoplayPolicy(type) method is called, the user agent MUST run the following steps ...

     followed by (for example):

     If the return value is disallowed, None of media, corresponding with the given type, are allowed to autoplay.

   Those two cases seem mutually exclusive - if "must" is true then it isn't "rough".

3. Note that the "rough" only seems to apply for the disallowed case. My assumption is that if you get allowed or allowed-muted you can trust the value for the specified type. However the policy would be set to disallowed if, for example, some media were allowed and others were not, for whatever reason. Is that correct?

The context for this is that I'm writing MDN docs for this. It is not clear to me how the result for a type is useful if you can't trust it, so I'm trying to work out if you can ever trust it for any of the returned values.

[chrisn]

Thanks @hamishwillee. I renamed the issue to focus on your points 2 and 3, having fixed the typos.

[hamishwillee]

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.

[gkatsev]

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

[hamishwillee]

@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.

[gkatsev]

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.

[hamishwillee]

Possibly! Above my pay grade. I think the most important use case is met :-)