Re: [mediacapture-screen-share] Multi-capture (concurrent capture of multiple surfaces) (#204)


> 1. it assumes order doesn't matter

First, for those applications that care about it, it's trivial to specify that the API supports order. (And let UX worry about communicating it to the user.) [Sequences]( are ordered.

Second - see my response to bullet number 3.

> 2. the UX presented ignores the question of whether to include audio or not for each user choice

The "UX presented" was a mock illustrating what is generally possible. Don't worry, when it's time to ship, we'll have something much more refined. What matters for the W3C is that the API will specify that the user must be allowed to control whether audio is shared, and the question of whether it should controlled be per-surface or global. Let's focus on that.

> 3. users have no way to correlate choices made with their role in the application

For many applications, order doesn't matter and there are no roles.
* If an application records all screens for legal-compliance, it needs not label them. In the case of a lawsuit, a human being will watch all recorded screens.
* If an application streams some windows, a human being on the other end can choose which one they want to focus on. No need for labelling.

> 4. it doesn't handle duplication well (users wanting the same choice for multiple roles in the application)

I have technical answers to that ([cloning](, app-based UX, Capture Handle, etc.). But I think it would be a mistake to start that discussion at this time, as I believe we have run into a **severe methodological issue**. Please see my next comment.

GitHub Notification of comment by eladalon1983
Please view or discuss this issue at using your GitHub account

Sent via github-notify-ml as configured in

Received on Wednesday, 16 February 2022 11:16:53 UTC