We posted a detailed response to the TAG feedback https://github.com/w3ctag/design-reviews/issues/1218#issuecomment-5342165759
On Sun, Aug 16, 2026 at 10:55 AM Thomas Nguyen <[email protected]> wrote: > 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/CACfOCkYz%3DvJZc%3DOGGHnoKD5EXB-_8c3AFfkbjOMpFY6o-W77hA%40mail.gmail.com.
