Thank you for the confirmation, Ravjit. That is correct; this is the first step (MVP launch) for the media capture elements. We will continue working on the specs and implementation simultaneously, based on the issues listed under the "Media Capture Elements" tag at https://github.com/w3c/mediacapture-extensions/issues.
The TAG review's concerns are not in the scope in this launch, but we will work closely with the WebRTC Working Group and other browser vendors to address these issues in the next versions. On Wednesday, August 12, 2026 at 5:10:01 PM UTC+2 [email protected] wrote: > Hey, do you have a comment on the TAG feedback that has been provided > recently? > > https://github.com/w3ctag/design-reviews/issues/1218#issuecomment-5166983302 > > On Wednesday, August 12, 2026 at 11:09:03 AM UTC-4 Alex Russell wrote: > >> Thanks for the usage data. LGTM2. >> >> Are you able to share anything about developer interest? Presumably you >> have partners engaged with this given the previous PEPC element experience, >> but would be good to confirm. >> >> On Tuesday, August 11, 2026 at 9:14:50 AM UTC-7 Rick Byers wrote: >> >>> 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 <[email protected]> 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 >>>> >>>> >>>> On Tue, Aug 11, 2026 at 5:32 PM Rick Byers <[email protected]> wrote: >>>> >>>>> Thanks Thomas! >>>>> >>>>> Looks like the tests are all failing upstream on wpt.fyi >>>>> <https://wpt.fyi/results/html/semantics/permission-element?label=master&label=experimental&aligned>, >>>>> >>>>> 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 <https://web-platform-tests.org/writing-tests/file-names.html> >>>>> is no longer accurate. >>>>> >>>>> Thanks! >>>>> Rick >>>>> >>>>> On Mon, Aug 10, 2026 at 3:52 PM Philipp Hancke < >>>>> [email protected]> wrote: >>>>> >>>>>> https://webrtchacks.github.io/chromestatus/?buckets=1401,1402 >>>>>> -- 0.25% of pageloads ;-) >>>>>> >>>>>> Am Mo., 10. Aug. 2026 um 21:06 Uhr schrieb Alex Russell < >>>>>> [email protected]>: >>>>>> >>>>>>> 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 >>>>>>> >>>>>>> On Friday, August 7, 2026 at 4:22:43 AM UTC-7 [email protected] >>>>>>> wrote: >>>>>>> >>>>>>>> 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/4e0e9e38-fbf8-40aa-964d-787882e8a4f7n%40chromium.org >>>>>>> >>>>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/4e0e9e38-fbf8-40aa-964d-787882e8a4f7n%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/57670ae0-130b-42a7-ac0d-a00310bd2354n%40chromium.org.
