> > Thanks for the standards position requests. But they reference > https://github.com/w3c/mediacapture-extensions/pull/168 which is more > recent, has outstanding review comments, and looks quite different ( > preview > <https://pr-preview.s3.amazonaws.com/tungnh28/mediacapture-extensions/pull/168.html#media-capture-html-elements> > , explainer > <https://github.com/tungnh28/mediacapture-extensions/blob/5884ebfb706ff227da2429447470c53b11ec6fa0/media-capture-elements-explainer.md>) > from spec references and explainers in this I2S. > For clarity on how those requests relate to this I2S, what exactly is > intended to ship? Will <usermedia> deviate from what's described in > the standards position requests, and if so how?
That’s a good catch. The explainer in https://github.com/w3c/mediacapture-extensions/pull/168 is the most accurate reflection of the plan (including both MVP for <usermedia> and post-MVP <camera> and <microphone> shipping). I'll make sure the I2S document is updated to point to that link as soon as it lands. The *"Goals for experimentation"* part that was removed mentioned: > *"To ensure a seamless transition and prevent disruption for our valued OT > partners, this trial will initially launch with an API shape that is > functionally equivalent to the previous <permission> trial, simply using > the new <usermedia> element name".*Does this also apply to what's > shipping? A lot of the agreement that was reached over this API came from > abandoning the request permission-ahead-of-use in favor of the established > permission-at-point-of-use model on the web. > Specifically, will the MVP <usermedia> element allow requesting > permission ahead of turning on camera/microphone devices? If yes, do you > have a migration path away from that model, as it is generally a regression > of the web model that is web incompatible? You’re right, the original OT had a different scope. To address the concerns in the MVP launch, we are implementing a migration path allowing sites to opt into the new element at their own pace (while keeping the behavior the same as the generic permission element), and we are evaluating a reverse OT to further assist this transition. To ensure a smooth transition for developers, we have prepared a migration document detailing the necessary steps. I'll update the doc as a public link and share it here shortly. (or in the above PR). On Fri, May 1, 2026 at 8:08 PM Jan-Ivar Bruaroey <[email protected]> wrote: > On Thursday, April 23, 2026 at 11:02:51 AM UTC-4 Minh Le wrote: > > Hi Dan, > thank you for the reminder, here are the standard positions requests > > - https://github.com/WebKit/standards-positions/issues/651 > - https://github.com/mozilla/standards-positions/issues/1392 > > > Thanks for the standards position requests. But they reference > https://github.com/w3c/mediacapture-extensions/pull/168 which is more > recent, has outstanding review comments, and looks quite different ( > preview > <https://pr-preview.s3.amazonaws.com/tungnh28/mediacapture-extensions/pull/168.html#media-capture-html-elements>, > explainer > <https://github.com/tungnh28/mediacapture-extensions/blob/5884ebfb706ff227da2429447470c53b11ec6fa0/media-capture-elements-explainer.md>) > from spec references and explainers in this I2S. > > For clarity on how those requests relate to this I2S, what exactly is > intended to ship? Will <usermedia> deviate from what's described in > the standards position requests, and if so how? > > The *"Goals for experimentation"* part that was removed mentioned: *"To > ensure a seamless transition and prevent disruption for our valued OT > partners, this trial will initially launch with an API shape that is > functionally equivalent to the previous <permission> trial, simply using > the new <usermedia> element name".* > > Does this also apply to what's shipping? A lot of the agreement that was > reached over this API came from abandoning the request > permission-ahead-of-use in favor of the established > permission-at-point-of-use model on the web. > > Specifically, will the MVP <usermedia> element allow requesting permission > ahead of turning on camera/microphone devices? If yes, do you have a > migration path away from that model, as it is generally a regression of the > web model that is web incompatible? > > On Wednesday, April 29, 2026 at 11:19:55 AM UTC-4 [email protected] > wrote: > >> LGTM3 >> >> On Tuesday, April 28, 2026 at 11:23:38 AM UTC-7 [email protected] wrote: >> >>> Please update the chromestatus entry to specify the new TAG review for >>>> <usermedia> rather than the old PEPC one, and link to the new webkit >>>> standards position. >>> >>> Done, thanks. >>> >>> Also, this I2S specifies "goals for experimentation" - why is that >>>> there? You're asking to fully ship, right? >>> >>> I think that's a left over we filled in in the OT request. Removed that. >>> >>> On Tue, Apr 28, 2026 at 5:55 PM Chris Harrelson <[email protected]> >>> wrote: >>> >> Please update the chromestatus entry to specify the new TAG review for >>>> <usermedia> rather than the old PEPC one, and link to the new webkit >>>> standards position. >>>> >>>> Also, this I2S specifies "goals for experimentation" - why is that >>>> there? You're asking to fully ship, right? >>>> >>>> On Mon, Apr 27, 2026 at 2:51 AM 'Thomas Nguyen' via blink-dev < >>>> [email protected]> wrote: >>>> >>> That sounds like a solid idea. Thank you for the suggestion, Philipp; I >>>>> have noted it down. >>>>> We will certainly add this to our roadmap and include the sample after >>>>> the API is merged into the media capture extensions. This will ensure >>>>> better alignment with the approved shape. >>>>> >>>>> >>>>> On Sat, Apr 25, 2026 at 4:57 PM Philipp Hancke < >>>>> [email protected]> wrote: >>>>> >>>> Looking forward to this shipping! Can you please also add a sample to >>>>>> https://github.com/webrtc/samples >>>>>> which remains a go-to location for all things getUserMedia and WebRTC >>>>>> (maybe we can get it to 15k stars finally ;-)) >>>>>> >>>>>> Am Mi., 15. Apr. 2026 um 16:39 Uhr schrieb Chromestatus < >>>>>> [email protected]>: >>>>>> >>>>> *Contact emails* >>>>>>> [email protected], [email protected] >>>>>>> >>>>>>> *Explainer* >>>>>>> https://github.com/WICG/PEPC/blob/main/usermedia_element.md >>>>>>> >>>>>>> *Specification* >>>>>>> https://wicg.github.io/PEPC/permission-elements.html >>>>>>> >>>>>>> *Summary* >>>>>>> Usermedia Capability Element, is a declarative, user-activated >>>>>>> control for accessing the starting and interacting with media streams. >>>>>>> This >>>>>>> addresses the long-standing problem of permission prompts being >>>>>>> triggered >>>>>>> directly from JavaScript without a strong signal of user intent. By >>>>>>> embedding a browser-controlled element in the page, the user's click >>>>>>> provides a clear, intentional signal. This enables a much better prompt >>>>>>> UX >>>>>>> and, crucially, provides a simple recovery path for users who have >>>>>>> previously denied the permission. Note: This feature was previously >>>>>>> developed and tested in an Origin Trial as the more generic <permission> >>>>>>> element. Based on feedback from developers and other browser vendors, it >>>>>>> has evolved into capability-specific elements to provide a more tailored >>>>>>> and powerful developer experience. >>>>>>> >>>>>>> *Blink component* >>>>>>> Public Trackers > Chromium Public Trackers > Chromium > Internals > >>>>>>> Permissions > PermissionElement >>>>>>> <https://issues.chromium.org/issues?q=customfield1222907:%22Public%20Trackers%20%3E%20Chromium%20Public%20Trackers%20%3E%20Chromium%20%3E%20Internals%20%3E%20Permissions%20%3E%20PermissionElement%22> >>>>>>> >>>>>>> *Web Feature ID* >>>>>>> permissions <https://webstatus.dev/features/permissions> >>>>>>> >>>>>>> *Motivation* >>>>>>> The current web permission model for interacting with user media >>>>>>> relies on JavaScript-triggered prompts, giving the user agent no strong >>>>>>> signal of user intent. This results in out-of-context prompts, user >>>>>>> frustration, and difficult-to-recover-from denial states. We propose the >>>>>>> <usermedia> element, or a suite of elements. This will be semantic HTML >>>>>>> control with browser-controlled content and strict styling constraints. >>>>>>> These constraints are fundamental to the security model, ensuring a very >>>>>>> high level of confidence in the user's intent when making a permission >>>>>>> decision at both the site and OS level. Crucially, the <usermedia> >>>>>>> element >>>>>>> evolves beyond simply managing permissions; it streamlines the entire >>>>>>> journey by also facilitating starting and interacting with media >>>>>>> streams. >>>>>>> This often eliminates the need for separate JavaScript API calls, >>>>>>> simplifying implementation and creating a more seamless user flow. By >>>>>>> providing a clear, consistent, in-page control, this element solves >>>>>>> significant user problems related to context blindness and "permission >>>>>>> regret," offering a simple recovery path from a previously denied state. >>>>>>> The combination of a user-initiated element and a subsequent >>>>>>> browser-controlled confirmation UI enhances intent capture, improves >>>>>>> accessibility, and prevents manipulative patterns, providing a >>>>>>> significantly better experience for both users and developers. >>>>>>> >>>>>>> *Initial public proposal* >>>>>>> https://github.com/WICG/PEPC/issues/62 >>>>>>> >>>>>>> *TAG review* >>>>>>> https://github.com/w3ctag/design-reviews/issues/1079 >>>>>>> >>>>>>> *TAG review status* >>>>>>> Issues addressed >>>>>>> >>>>>>> *Origin Trial Name* >>>>>>> UserMediaElement >>>>>>> >>>>>>> *Goals for experimentation* >>>>>>> This Origin Trial serves two primary purposes: ensuring continuity >>>>>>> for existing partners who have successfully integrated this pattern, and >>>>>>> providing a platform to validate and iterate on the new, >>>>>>> capability-specific <usermedia> element. While our previous Origin Trial >>>>>>> for <permission> provided strong evidence for the core user-initiated >>>>>>> model, feedback from developers and browser vendors prompted us to >>>>>>> evolve >>>>>>> the design. This new trial is essential for gathering insights on a >>>>>>> refined, data-centric API shape to help us reach cross-browser >>>>>>> consensus. >>>>>>> To ensure a seamless transition and prevent disruption for our valued OT >>>>>>> partners, this trial will initially launch with an API shape that is >>>>>>> functionally equivalent to the previous <permission> trial, simply using >>>>>>> the new <usermedia> element name. This provides a stable foundation from >>>>>>> which we will iterate based on further discussion. Our goal is to evolve >>>>>>> this element towards our proposed data-centric design ( >>>>>>> https://github.com/WICG/PEPC/blob/main/usermedia_element.md). >>>>>>> However, we recognize that this more advanced API has raised >>>>>>> compatibility >>>>>>> and complexity concerns with developers ( >>>>>>> https://github.com/WICG/PEPC/issues/62). Therefore, a primary >>>>>>> objective of this trial is to work closely with the community to address >>>>>>> these concerns and refine the final API. TPAC WebRTC minutes >>>>>>> https://www.w3.org/2025/11/11-webrtc-minutes.html#551 >>>>>>> >>>>>>> *Chromium Trial Name* >>>>>>> UserMediaElement >>>>>>> >>>>>>> *Origin Trial documentation link* >>>>>>> https://github.com/WICG/PEPC/blob/main/usermedia_element.md >>>>>>> >>>>>>> *WebFeature UseCounter name* >>>>>>> kHTMLPermissionElement >>>>>>> >>>>>>> *Risks* >>>>>>> >>>>>>> >>>>>>> *Interoperability and Compatibility* >>>>>>> There is a risk that this feature fails to be adopted by other >>>>>>> browsers. This can be mitigated by backwards designing a reasonable >>>>>>> fallback mechanism so that the element can degrade gracefully if the >>>>>>> it's >>>>>>> in an unsupported environment. >>>>>>> >>>>>>> *Gecko*: Under consideration ( >>>>>>> https://github.com/mozilla/standards-positions/issues/1245) >>>>>>> >>>>>>> *WebKit*: No signal >>>>>>> >>>>>>> *Web developers*: Positive >>>>>>> https://github.com/WICG/PEPC/issues/2#issuecomment-2393820279 >>>>>>> https://github.com/WICG/PEPC/issues/2#issuecomment-2393861768 >>>>>>> https://github.com/WICG/PEPC/issues/2#issuecomment-2393911331 >>>>>>> https://github.com/WICG/PEPC/issues/2#issuecomment-2619657041 >>>>>>> https://github.com/WICG/PEPC/issues/62#issuecomment-3482975001 >>>>>>> https://github.com/WICG/PEPC/issues/62#issuecomment-3482981942 >>>>>>> https://github.com/WICG/PEPC/issues/62#issuecomment-3498355775 >>>>>>> https://github.com/WICG/PEPC/issues/62#issuecomment-3513734884 >>>>>>> >>>>>>> *Other signals*: >>>>>>> >>>>>>> *Ergonomics* >>>>>>> No foreseen ergonomics risks. >>>>>>> >>>>>>> *Activation* >>>>>>> A polyfill can help developers use this feature without risking >>>>>>> broken functionality on non-supporting browsers. >>>>>>> >>>>>>> *Security* >>>>>>> https://github.com/WICG/PEPC/blob/main/explainer.md#Security >>>>>>> >>>>>>> *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? >>>>>>> Feature is not shipping on WebView due to it requiring permission >>>>>>> manager embedder support. >>>>>>> >>>>>>> >>>>>>> *Debuggability* >>>>>>> The element raises issues to the devtools issues panel which help >>>>>>> developers debug issues with their usage of the element. >>>>>>> >>>>>>> *Will this feature be supported on all six Blink platforms (Windows, >>>>>>> Mac, Linux, ChromeOS, Android, and Android WebView)?* >>>>>>> No >>>>>>> The element is not supported on Android WebView as it requires >>>>>>> permission manager support to function and the WebView permission >>>>>>> manager >>>>>>> defers most permission decisions to the embedder by design. >>>>>>> >>>>>>> *Is this feature fully tested by web-platform-tests >>>>>>> <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md>?* >>>>>>> Yes >>>>>>> https://wpt.fyi/results/html/semantics/permission-element/usermedia >>>>>>> >>>>>>> *DevTrial instructions* >>>>>>> https://github.com/WICG/PEPC/blob/main/HOWTO.md#enabling-usermedia >>>>>>> >>>>>>> *Flag name on about://flags* >>>>>>> *No information provided* >>>>>>> >>>>>>> *Finch feature name* >>>>>>> UserMediaElement >>>>>>> >>>>>>> *Rollout plan* >>>>>>> Will ship enabled for all users >>>>>>> >>>>>>> *Requires code in //chrome?* >>>>>>> True >>>>>>> >>>>>>> *Tracking bug* >>>>>>> https://crbug.com/443013457 >>>>>>> >>>>>>> *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 publish 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 desktop 149 >>>>>>> Origin trial desktop first 144 >>>>>>> Origin trial desktop last 148 >>>>>>> DevTrial on desktop 144 >>>>>>> Shipping on Android 149 >>>>>>> Origin trial Android first 144 >>>>>>> Origin trial Android last 148 >>>>>>> DevTrial on Android 144 >>>>>>> >>>>>>> *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 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. Some of the open topics are for example: In >>>>>>> the future, we might want to add a parameter to the getUserMedia >>>>>>> algorithm >>>>>>> so that the algorithm can determine whether the getUserMedia is called >>>>>>> from >>>>>>> the <usermedia> element or getUserMedia API. Potential to add additional >>>>>>> attributes for <usermedia> interface. We're putting finishing touches on >>>>>>> the spec now, work-in-progress PR is here, but once that lands we want >>>>>>> to >>>>>>> ship for M149 so wanted to start the discussion now. >>>>>>> >>>>>>> *Link to entry on the Chrome Platform Status* >>>>>>> >>>>>>> https://chromestatus.com/feature/4926233538330624?gate=6467532078841856 >>>>>>> >>>>>>> *Links to previous Intent discussions* >>>>>>> Intent to Prototype: >>>>>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/692719de.050a0220.17ec37.00c3.GAE%40google.com >>>>>>> Intent to Experiment: >>>>>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/6942ed09.050a0220.1050d6.0961.GAE%40google.com >>>>>>> >>>>>>> >>>>>>> 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/69dfa184.050a0220.c8e20.03e8.GAE%40google.com >>>>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/69dfa184.050a0220.c8e20.03e8.GAE%40google.com?utm_medium=email&utm_source=footer> >>>>>>> . >>>>>>> >>>>>> >>>>> >>>>> -- >>>>> >>>>> Thomas Nguyen >>>>> >>>>> Software Engineer >>>>> >>>>> [email protected] >>>>> >>>>> Google Germany GmbH >>>>> >>>>> Erika-Mann-Straße 33 >>>>> >>>>> 80636 München >>>>> >>>>> Geschäftsführer: Paul Manicle, Halimah DeLaine Prado >>>>> >>>>> Registergericht und -nummer: Hamburg, HRB 86891 >>>>> >>>>> Sitz der Gesellschaft: Hamburg >>>>> >>>>> Diese E-Mail ist vertraulich. Falls Sie diese fälschlicherweise >>>>> erhalten haben sollten, leiten Sie diese bitte nicht an jemand anderes >>>>> weiter, löschen Sie alle Kopien und Anhänge davon und lassen Sie mich >>>>> bitte >>>>> wissen, dass die E-Mail an die falsche Person gesendet wurde. >>>>> >>>>> >>>>> >>>>> This e-mail is confidential. If you received this communication by >>>>> mistake, please don't forward it to anyone else, please erase all copies >>>>> and attachments, and please let me know that it has gone to the wrong >>>>> person. >>>>> >>>>> -- >>>>> 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/CA%2BoJCSxCm3w%3DJSaikf6HwAfYe%3DgwrOi7rR%2Bi3Uz2sybR_Uuhew%40mail.gmail.com >>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CA%2BoJCSxCm3w%3DJSaikf6HwAfYe%3DgwrOi7rR%2Bi3Uz2sybR_Uuhew%40mail.gmail.com?utm_medium=email&utm_source=footer> >>>>> . >>>>> >>>> >>> >>> -- >>> >>> Thomas Nguyen >>> >>> Software Engineer >>> >>> [email protected] >>> >>> Google Germany GmbH >>> >>> Erika-Mann-Straße 33 >>> >>> 80636 München >>> >>> Geschäftsführer: Paul Manicle, Halimah DeLaine Prado >>> >>> Registergericht und -nummer: Hamburg, HRB 86891 >>> >>> Sitz der Gesellschaft: Hamburg >>> >>> Diese E-Mail ist vertraulich. Falls Sie diese fälschlicherweise erhalten >>> haben sollten, leiten Sie diese bitte nicht an jemand anderes weiter, >>> löschen Sie alle Kopien und Anhänge davon und lassen Sie mich bitte wissen, >>> dass die E-Mail an die falsche Person gesendet wurde. >>> >>> >>> >>> This e-mail is confidential. If you received this communication by >>> mistake, please don't forward it to anyone else, please erase all copies >>> and attachments, and please let me know that it has gone to the wrong >>> person. >>> >> -- Thomas Nguyen Software Engineer [email protected] Google Germany GmbH Erika-Mann-Straße 33 80636 München Geschäftsführer: Paul Manicle, Halimah DeLaine Prado Registergericht und -nummer: Hamburg, HRB 86891 Sitz der Gesellschaft: Hamburg Diese E-Mail ist vertraulich. Falls Sie diese fälschlicherweise erhalten haben sollten, leiten Sie diese bitte nicht an jemand anderes weiter, löschen Sie alle Kopien und Anhänge davon und lassen Sie mich bitte wissen, dass die E-Mail an die falsche Person gesendet wurde. This e-mail is confidential. If you received this communication by mistake, please don't forward it to anyone else, please erase all copies and attachments, and please let me know that it has gone to the wrong person. -- 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/CA%2BoJCSwo%3Du6bGD5C7M0bnr1mNbnregxxx8gsLzaTUEFpc0_bEQ%40mail.gmail.com.
