- From: Jan-Ivar Bruaroey via GitHub <sysbot+gh@w3.org>
- Date: Mon, 21 Oct 2024 23:10:47 +0000
- To: public-webrtc-logs@w3.org
> It's not clear to me which heavy machinery is required. If a browser wishes to have a trivial, always-granted permission of the `"captured-surface-control"` permission policy:
>
> * Does the spec not already permit that?
> * Is there a non-trivial cost to the implementers of that browser?
Appeal to Triviality arguments for implementing something run afoul of [ยง 1.7. Add new capabilities with care](https://w3ctag.github.io/design-principles/#new-features).
A new permission adds:
- A new iframe `allow="display-capture https://a.com; captured-surface-control https://a.com;"` that web developers need to turn on explicitly
- A new `permissions.query({name: "captured-surface-control"})` value web developers need to consider
- [Implementation-defined behavior](https://www.w3.org/TR/permissions/#requesting-more-permission) web developers need to consider for interop
<img width="766" alt="image" src="https://github.com/user-attachments/assets/8c29c66e-1c92-41be-8448-d03cc031c602">
One might even say a new permission without good reason is a failure to standardize.
I've not heard a good reason yet for this level of granularity at the iframe level, or at the prompt level.
If there's a way to avoid this extra level of complexity for web developers (not vendors), I'd like to exhaust those ideas first.
--
GitHub Notification of comment by jan-ivar
Please view or discuss this issue at https://github.com/w3c/mediacapture-screen-share-extensions/issues/14#issuecomment-2427900425 using your GitHub account
--
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Monday, 21 October 2024 23:10:48 UTC