Intent to Ship: Capability elements: <camera> and <microphone>

[Chromestatus]

Contact emails

tun...@google.com, rav...@google.com

Explainer

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

Specification

https://w3c.github.io/mediacapture-extensions/#the-camera-html-element

Summary

The <camera> and <microphone> capability elements are declarative, user-activated HTML controls that share the same underlying mechanism as the <usermedia> MVP element, with one key distinction: they are designed to request a single capability. The <camera> element specifically requests video capture, while the <microphone> element specifically requests audio capture. Like the <usermedia> MVP, they embed a browser-controlled, strictly styled UI into the page, ensuring a strong, intentional user signal (a click) before a permission prompt is triggered or a stream is started. The <camera> and <microphone> elements provide a dedicated, semantic HTML control for these single-capability use cases. They maintain the identical security model, strict styling constraints, and built-in permission recovery path as the <usermedia> MVP, but offer a more tailored and ergonomic API for developers who do not need mixed media access.

Blink component

UI>Browser>Permissions>Prompts

Web Feature ID

permissions

Motivation

In M151, we shipped the <usermedia> element (MVP) to solve the problem of out-of-context, JavaScript-triggered permission prompts. By requiring a direct, in-page user click on a browser-controlled element, we ensure a strong signal of user intent before requesting media access. Based on feedback and the WICG specification, we are expanding this MVP model in M152. The <camera> and <microphone> elements use the exact same mechanism, security constraints, and UI behavior as the <usermedia> MVP, but are strictly scoped to single-capability capture. This provides a more ergonomic, semantic API for developers building applications that only require video or audio, streamlining the implementation while preserving our high-confidence intent capture.

Initial public proposal

No information provided

TAG review

https://github.com/w3ctag/design-reviews/issues/1218

TAG review status

Issues addressed

Goals for experimentation

None

Risks

Interoperability and Compatibility

No information provided

Gecko: No signal

WebKit: No signal

Web developers: No signals

Other signals:

WebView application risks

Does this intent deprecate or change behavior of existing APIs, such that it has potentially high risk for Android WebView-based applications?

No information provided

Debuggability

No information provided

Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, ChromeOS, Android, and Android WebView)?

No

Is this feature fully tested by web-platform-tests?

Yes

Flag name on about://flags

CameraAndMicrophoneElements

Finch feature name

No information provided

Non-finch justification

No information provided

Rollout plan

Will ship enabled for all users

Requires code in //chrome?

False

Tracking bug

https://b.corp.google.com/issues/531672795

Launch bug

https://launch.corp.google.com/launch/4486395

Availability expectation

Feature is available only in Chromium browsers. We are not aware of other browsers adoption.

Adoption expectation

Feature is used by specific partner(s) to provide functionality within 12 months of launch in Chrome. Partners who are tested the feature in OT are expected to continue usage.

Adoption plan

We are planning to update on developer.chrome.com and do further partner outreach

Non-OSS dependencies

Does the feature depend on any code or APIs outside the Chromium open source repository and its open-source dependencies to function?

No

Estimated milestones

Shipping on desktop	152
Shipping on Android	152

Anticipated spec changes

Open questions about a feature may be a source of future web compat or interop issues. Please list open issues (e.g. links to known github issues in the project for the feature specification) whose resolution may introduce web compat/interop risk (e.g., changing to naming or structure of the API in a non-backward-compatible way).

This is an extension of <usermedia> MVP launch. The MVP feature is fully functional and used by developers right now. We are working closely with the WebRTC on post-MVP features, the open topics will based on the foundation of the MVP, that we agreed upon with the WebRTC. The open topics are listed under WebRTC working group's github repo's issue. Once this lands we will start the post-MVP discussion.

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5153829504024576?gate=6067694366490624

This intent message was generated by Chrome Platform Status.

[Yoav Weiss (@Shopify)]

Do we have a signal for the broader "permission elements" concept?

 

Web developers: No signals

Other signals:

WebView application risks

Does this intent deprecate or change behavior of existing APIs, such that it has potentially high risk for Android WebView-based applications?

No information provided

Debuggability

No information provided

Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, ChromeOS, Android, and Android WebView)?

No

More details on that one?

 

Is this feature fully tested by web-platform-tests?

Yes

Link to the tests? 

[Rick Byers]

Was just looking at this and had the same questions Yoav. Here's what I've found so far:

No response from WebKit or Mozilla yet unfortunately:

https://github.com/WebKit/standards-positions/issues/651

https://github.com/mozilla/standards-positions/issues/1392

 

With that, I don't see the point of asking for a separate position on this variation (the tradeoffs are very similar).

 

Web developers: No signals

Other signals:

WebView application risks

Does this intent deprecate or change behavior of existing APIs, such that it has potentially high risk for Android WebView-based applications?

No information provided

Debuggability

No information provided

Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, ChromeOS, Android, and Android WebView)?

No

More details on that one?

I believe it's all platforms except WebView

 

Is this feature fully tested by web-platform-tests?

Yes

Link to the tests? 

I hear they're in progress but haven't landed yet. So given that this is a rather big feature, I'd like to see the tests on wpt.fyi before I give my approval. Otherwise looks great to me, I'm excited to see this ship!

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/f0bc1deb-4ab2-4b12-a17a-7fea26deebc4n%40chromium.org.

[Thomas Nguyen]

Thanks for taking a look.
I have filled in the missing bits (regarding wpt, linking the tests and platforms supported). Please let me know if you still have any concerns.

[Alex Russell]

Thanks for filing those.

I'm excited that we're adding HTML elements for common behaviours. Along those lines, do we have an analysis of how common camera and mic requests are today? I.e., can we make the case that this is so common that it deserves an HTML element?

Best,

Alex

[Philipp Hancke]

https://webrtchacks.github.io/chromestatus/?buckets=1401,1402

-- 0.25% of pageloads ;-)

To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/4e0e9e38-fbf8-40aa-964d-787882e8a4f7n%40chromium.org.

[Rick Byers]

Thanks Thomas!

Looks like the tests are all failing upstream on wpt.fyi, presumably because the feature is only status=test, not status=experimental. Is there a reason the feature wasn't flipped to status=experimental? To what extent do you expect the tests to pass upstream on wpt.fyi once you flip to status=stable?

Also can you now please remove the 'tentative' from your test filenames? Since there is a specification for them, the 'tentative' label is no longer accurate.

Thanks!

   Rick

[Rick Byers]

Excellent, thanks Ravjit! If you say the tests are passing, that's good enough for me (we can always backtrack if we find some surprise / bug we can't quickly fix). So LGTM1 to ship once the test names are corrected and assuming you'll check the wpt.fyi results after it lands and fix any issues before it reaches stable. 

It's your call if you want to land a change to status=experimental first. It doesn't hurt, and it might be useful if you don't immediately get 3 LGTMs.

Rick

On Tue, Aug 11, 2026 at 11:55 AM Ravjit Uppal <rav...@google.com> wrote:

Hi Rick, 

Thomas is OOO, so let me take this.
There was no particular reason for not changing the status to experimental. I will update the status to "experimental" before we switch it to "stable." Additionally, I will remove "tentative" from the file names. I expect all of them to be passing fairly consistently.

Thanks!
Ravjit