#1218: Media Capture Capability Elements (part of PEPC)

Visit on Github

Opened Apr 7, 2026

Specification

https://w3c.github.io/mediacapture-extensions/#media-capture-html-elements

Explainer

https://github.com/w3c/mediacapture-extensions/blob/main/media-capture-elements-explainer.md, https://github.com/WICG/PEPC/blob/main/usermedia_element.md, https://github.com/WICG/PEPC/blob/main/explainer.md

Links

  • Previous early design review, if any: This is an evolution of work previously reviewed by the TAG.
  • An introduction to the feature, aimed at unfamiliar audiences: TLDR.
  • A description of the problems that end-users were facing before this proposal: The same core user problem with previous design.
  • Alternatives considered: this proposal addresses feedback, to replace the previous design.
  • Examples of how to use the proposal to solve the end-users' problems: User journeys.
  • What do the end-users experience with this proposal: User journeys.
  • User research you did to validate the problem and/or design, if any: a research from the previous TAG review.
  • Web Platform Tests: tests.

The specification

Where and by whom is the work is being done?

  • GitHub repo: https://github.com/WICG/PEPC
  • Primary contacts:
    • Daniel Vogelheim (@otherdaniel), Google Chrome, Spec Writer
    • Minh Le (@MinhAnhL), Google Chrome, PM
    • Thomas Nguyen (@tungnh), Google Chrome, Engineer
  • Organization/project driving the specification: Google Chrome
  • This work is being funded by: Google Chrome
  • Primary standards group developing this feature: WebRTC Working Group.
  • Group intended to standardize this work: WebRTC Working Group.
  • Incubation and standards groups that have discussed the design:

Feedback so far

You should also know that...

  • Historical context: This is a subsequence step of <permission> element proposal, and in response to feedback and discussions, we are moving away from a single, generic permission element. Instead, we are proposing separate elements tailored to specific capabilities. After splitting and releasing the <geolocation> element proposal, we are now introducing the media capture (<usermedia>, <camera>, <microphone>) elements. This new elements will inherit all attributes, events, and checks from the <permission> element. Ultimately, the <permission> element will function solely as a base class for specialized capability elements and will not be for direct use.
  • The specification is currently hosted in a PEPC repository. We intend to request a review from the WebRTC's media capture extensions this week.
<!-- Content below this is maintained by @w3c-tag-bot -->

Track conversations at https://tag-github-bot.w3.org/gh/w3ctag/design-reviews/1218

Discussions

Log in to see TAG-private discussions.

Discussed Apr 6, 2026 (See Github)

Jeffrey: maybe Mike here?

Christian: sounds reasonable.

Ehsan: I might be interested, let me have a look.

Jeffrey: ok.

Discussed Apr 27, 2026 (See Github)

Jeffrey: if we notice anything, let's post to blink-dev, as the API owner has just approved it to ship. We asked them to make the element, but acted as if we'd approved the design of it, which is not the case - I pointed that out, but if we have comments we should make them on blink-dev first.

Discussed May 11, 2026 (See Github)

Matthew: Ehsan put in a comment on that one.

Jeffrey: That’s on whether the user media explainer needs it’s own S&P section. Which I agree with. Don’t think we need to block on them adding them, and then do the review. However, I expect there are interesting implications for usermedia where they should consider alternatives.

Brian: Is it shipped?

Jeffrey: It’s not shipped. They are pausing their launch and extending their origin trial. (https://groups.google.com/a/chromium.org/g/blink-dev/c/V_ef1L9BtHw/m/FTqZZLOSAQAJ) However, I don’t expect that we will get feedback in time. We should post those comments in parallel, with asking for the alternatives considered and other sections for this explainer.

Discussed May 18, 2026 (See Github)

Mike: Is feedback useful since it's shipping?

Lola: We can decline to review things if for whatever reason we don't want to review it. We'd write a comment. However, even when something has shipped or is close to shipping, our feedback can still be helpful. It's good to have a written record of what we thought, even if it doesn't cause implementation changes.

Jeffrey: Eevn though this is close to shipping in Chrome, it's not close in the other browsers. There's a window to effect their implementations, and that could impact Chrome.

Luke: FWIW, it's not shipping in Chromium. The I2S was paused to extend the Origin Trial for ~3 versions.

Mike will continue reviewing.

Discussed Jun 8, 2026 (See Github)

Mike: Essan got back with some extra thoughts this morning... someone else in our group I thought had said they were going to give it another review, but I don't remember who that was - it wasn't Jeffrey. I wasn't sure if Essan wanted to modify my comment or not... What is the procedure here?

Lola: I would just ask him in slack

Mike: I just looked it up it was heather who said she wanted to look

Lola: ping her in slack too

Matthew: One of you I think said this could be a place to standardize play pause... That's a bit where you migth want to combine forces a bit.

Discussed Jun 22, 2026 (See Github)

Mike: Moving forward with Heather and Ehsan. We are consolidating input. Expect to post a comment tomorrow.

Discussed Jun 29, 2026 (See Github)

(Skipped.)

Discussed Jun 29, 2026 (See Github)

Mike: Last week Ehsan volunteered to incorporate feedback into the comment and post it. I'll ping Ehsan in Slack.

Discussed Jul 6, 2026 (See Github)
<skip>
Comment by @slightlyoff Jul 27, 2026 (See Github)

FYI that there's a new Chromium/Blink I2S citing this review; if the TAG wants to weigh in, the time is now:

https://groups.google.com/a/chromium.org/g/blink-dev/c/Iaoq0CYadzo/m/4NcvzdVqFwAJ

Comment by @toreini Aug 3, 2026 (See Github)

Thanks for submitting this work. We have the following concerns regarding this spec and request clarification:

  1. The spec should require that the mute trigger be origin-bound and device-bound. (This is for consistency with Media Stream permission policy requirements.)

  2. Whether using getUserMedia() or the latest version of this proposal, every app that offers to "mute" a device retains the prerogative to unmute that device at any moment. Do you see any opportunities to provide security guarantees to users, that their camera will not suddenly be re-activated without their consent? (following the encoureged behaviour in Media Stream permission policy)

We feel that there should be potential for UA interaction to reassure users that once their camera/audio is muted, it will not be suddenly re-activated without their consent. Does this design leave some space to explore solutions to this problem? Do you think it would be possible to standardize such guarantees?

  1. This spec will fomalise the following action-sequence: mute → unmute → mute. As the mute action is already fomally defined in Media Capture and Streams. We request the spec developers consider a clear definition for the action sequence to avoid confusion.

Furthermore, we have some observations regarding the explainer:

  • There are two links included: one related to PEPC (which was a separate TAG review) and another for <usermedia>. The explainer for the latter, which we assumed is the focus of this review, does not follow the standard format. It lacks sections such as "S&P considerations" and "alternatives considered" - these are important in order for readers and reviewers to understand the trade-offs made during the design of the proposal. Can you please update the explainer to be consistent with the explainer format?

    Note: You may find the similar discussions in the <geolocation> explainer helpful.