On Wednesday, July 22, 2026 at 11:47:33 PM UTC+2 Chromestatus wrote:
*Contact emails* [email protected], [email protected] *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 <https://issues.chromium.org/issues?q=customfield1222907:%22UI%3EBrowser%3EPermissions%3EPrompts%22> *Web Feature ID* permissions <https://webstatus.dev/features/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 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 <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md>?* Yes Link to the tests? *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 desktop152 Shipping on Android152 *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 <https://chromestatus.com>. -- 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 [email protected]. To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/f0bc1deb-4ab2-4b12-a17a-7fea26deebc4n%40chromium.org.
