Add proposed explainer

[beccahughes]

This is a proposed explainer for the W3C TAG review. This is not final and we should alter the design based on the resolution of the async vs sync issue (hence leaving this as a PR for now as it is easier to leave comments).

@mounirlamouri @padenot @jyavenard @eric-carlson @hober @jernoble

[beccahughes]

Design review is here: w3ctag/design-reviews#356

[padenot]

I've posted my comment in #7, as originally planned. I think the layout of issue #7 is better at this stage of the discussion, as it present the three (really, two, iirc what happened in the meeting) alternatives without an explicit hierarchization: writing the examples in the async style and relegating the other API styles in another section.

[marcoscaceres]

👋 hi! just checking in a seeing if anything is happening with this proposal/incubation? Is there consensus to move it forward?

[eric-carlson]

👋 hi! just checking in a seeing if anything is happening with this proposal/incubation? Is there consensus to move it forward?

The TAG remanded this issue to the Media WG. It is now part of the Media WG charter , so it should probably be moved from the WICG.

[hober]

clarification: the TAG review didn’t cause the venue change, @eric-carlson.

[marcoscaceres]

Ok, cool... does that means moving the whole repository or will "the good parts" be moved into some existing spec?

[mounirlamouri]

We should move the whole repo. We have a bunch of repo to move to w3c/ and I was waiting to hear from François Daoust to check how to do that as I assume I can't just drop repos in the w3c org :)

[marcoscaceres]

Ok cool. Let me know which ones, and to which working groups, and we Chairs can help too. “Graduating” incubations to W3C Working Groups is our goal, so we are happy to help.

[mounirlamouri]

Let's move over email instead of spamming this PR 😃

[chrisn]

Can we merge this PR? It would be good to have an explainer in place for when @alastor0325 is ready to create a spec.

[jyavenard]

Where would this be merged?

the TAG reviewed and the decision was made to move the canautoplay detection synchronous, making most of this explainer obsolete..

[chrisn]

It's currently on a branch on this repo, so the idea would be to merge to main here. But, if the explainer doesn't reflect current thinking, we should redraft.

[alastor0325]

I think we could just obsolete this explainer because it contains some async information that we won't use for the spec. I've already started editing the spec and will update the spec draft after we determine the final naming for API in #12.

[chrisn]

I would recommend that we create an explainer in any case, as it will help as we go through W3C review process - and TAG will want to see it if and when we ask another TAG review.

[gkatsev]

Yeah, an explainer on the need for both a document and a video element property would be helpful, I think.

[alastor0325]

Close this PR because we have already started implement a draft (this explainer is based on old discussion, which is out-of-date)

[chrisn]

Reopening, as we'll need the explainer when we request TAG review for #30. I'll update it to reflect the draft spec API shape and remove the sync/async discussion.

[chrisn]

Some things still to add:

• Describe the benefit to end-users, not just the benefit to web developers (TAG reviews often look for this)
• Explain why we have per-element and per-document queries and when each should be used
• Describe a Web Audio example

@alastor0325 @liberato-at-chromium for review, edits welcome.