Thank you for following up! LGTM3
On Wednesday, August 19, 2026 at 8:43:28 AM UTC-4 [email protected] wrote: > 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/78e18012-d64c-4bbf-822a-e876b93530c0n%40chromium.org.
