@Alex: Meet has a tentative plan to use these elements after M153. And we also have Cisco (WebEx), 8x8 and Zoom in the active communication channel.
@Vladimir: We will post a detailed response to the feedback directly there, but I can give you the gist of it here. Yes we do want to handle mute/unmute trigger from the UA's side in the near future. We have taken this out of the spec & our implementation, because several aspects of it were unclear, and there was no agreement with the WebRTC editors. Progress on that topic is tracked here: https://github.com/w3c/mediacapture-extensions/issues/170 On Wed, Aug 12, 2026 at 5:10 PM Vladimir Levin <[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/CACfOCkYT1moiRGSn8hbiYdbXC7S%2B%2Bq2Hux0UAiTSy167wp4yiQ%40mail.gmail.com.
