Intent to Prototype: Context-aware media element(s)

[Chromestatus]

Contact emails

lemi...@google.com, tun...@google.com

Explainer

https://github.com/WICG/PEPC/blob/main/usermedia_element.md
https://github.com/WICG/PEPC/blob/main/explainer.md

Specification

https://wicg.github.io/PEPC/permission-elements.html

Summary

Context-aware media element(s), are 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

Blink>PermissionsAPI

Web Feature ID

permissions

Motivation

The current web permission model for geolocation 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 directly providing location data to the site. 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

Requires code in //chrome?

True

Tracking bug

https://crbug.com/443013457

Estimated milestones

No milestones specified

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/4926233538330624?gate=5724196451778560

This intent message was generated by Chrome Platform Status.

[Reilly Grant]

On Wed, Nov 26, 2025 at 7:17 AM Chromestatus <ad...@cr-status.appspotmail.com> wrote:

Contact emails

lemi...@google.com, tun...@google.com

Explainer

https://github.com/WICG/PEPC/blob/main/usermedia_element.md
https://github.com/WICG/PEPC/blob/main/explainer.md

Specification

https://wicg.github.io/PEPC/permission-elements.html

Summary

Context-aware media element(s), are 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

Blink>PermissionsAPI

Web Feature ID

permissions

Motivation

The current web permission model for geolocation relies on JavaScript-triggered prompts, giving the user agent no strong signal of user intent.

I believe this was meant to say "user media".

 

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 directly providing location data to the site. 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

Requires code in //chrome?

True

Tracking bug

https://crbug.com/443013457

Estimated milestones

No milestones specified

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/4926233538330624?gate=5724196451778560

This intent message was generated by Chrome Platform Status.

--
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 blink-dev+...@chromium.org.
To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/692719de.050a0220.17ec37.00c3.GAE%40google.com.