- From: Daniel Appelquist <notifications@github.com>
- Date: Wed, 28 Aug 2024 00:49:59 -0700
- To: w3ctag/design-reviews <design-reviews@noreply.github.com>
- Cc: Subscribed <subscribed@noreply.github.com>
- Message-ID: <w3ctag/design-reviews/issues/954/2314579162@github.com>
Hi - somme pieces of feedback from our TAG breakout this morning where we reviewed this: It seems like the explainer is very lean. We think that there are a number of issues that need to be more fully explored before we can be more sure about this proposal. In the use case that you're sharing a specific content area to an embedded iFrame (the use case in the explainer) what is the permissions flow for this scenario? For example - in current screen sharing scenarios, the user may be prompted to share a tab, a window, or the whole screen. What would the user be prompted for in this case? Would they be able to choose an alternative sharing target such as an other tab or the screen or is it envisioned that in this case they would be constrained to only share content from the designated application? Can this be treated like an extension to [ViewPortCapture](https://w3c.github.io/mediacapture-viewport/)? We note that this sort of sharing carries similar security risks at that API, and the additional constraints on capture in that API might be better suited to this use case than the more general getDisplayMedia. The proposed API starts by preparing to share the whole of the content, and then restricting it to a particlar part - have you considered ways to _start_ with the specific part to be shared instead? (How would this affect occlusion? You have a goal of avoiding occlusion, but what about elements that are partially-transparent? Would this capture what is rendered behind an element? -- Reply to this email directly or view it on GitHub: https://github.com/w3ctag/design-reviews/issues/954#issuecomment-2314579162 You are receiving this because you are subscribed to this thread. Message ID: <w3ctag/design-reviews/issues/954/2314579162@github.com>
Received on Wednesday, 28 August 2024 07:50:03 UTC