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.
On Wednesday, July 29, 2026 at 5:06:59 PM UTC+2 [email protected] wrote: > Was just looking at this and had the same questions Yoav. Here's what I've > found so far: > > On Wed, Jul 29, 2026 at 10:22 AM Yoav Weiss (@Shopify) < > [email protected]> wrote: > >> >> >> 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? >> > > 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 >> <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md>?* >> 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! > > >> *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 >> >> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/f0bc1deb-4ab2-4b12-a17a-7fea26deebc4n%40chromium.org?utm_medium=email&utm_source=footer> >> . >> > -- 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/2559e805-1ada-4292-a765-84efa28955afn%40chromium.org.
