Re: [mediacapture-screen-share-extensions] Tab capture control (#13)

> > partial interface HTMLVideoElement {
> >  attribute boolean enableGestureForwarding;
> > };
>
> I favor this API.

As we have covered on multiple threads ([[1]](https://github.com/screen-share/captured-surface-control/issues/27), [[2]](https://github.com/w3c/mediacapture-screen-share-extensions/issues/14)):
1. This would prevent the use of a permission policy (because it does not return a promise).
2. Web developers have a strong need for types other than HTMLVideoElement. (Rationale reiterated further down.)
3. Limiting to HTMLVideoElement does not block any attack vector, so the limitation has no justification.
4. What happens if the stream plugged into the HTMLVideoElement first goes through processing? This API shape scopes things to the track instead of the capture; this is a mistake.

Additionally:

5. This API shape would not lend itself well to extension of the list of element types.
6. This is not a reasonable point of exposure, as Web developers are not liable to understand that it relates to capture.

Points 2 and 3 are arguably captured by the previous discussion [here](https://github.com/screen-share/captured-surface-control/issues/28#issuecomment-2422934097), where I am still waiting for your response.


> > ```js
> >  controller.forwardGestures(e1, {wheel: true});
> > ```
>
> I do not favor this API. It allows mistakes like forwarding to a capture other than the one playing. Also, dictionary default rules mean `controller.forwardGestures(e1)` turns forwarding *off* which seems surprising and unintuitive.

The change from `captureWheel(element)` to `forwardGestures(element, gestures)` was intended to address Youenn's concerns about:
1. Extensibility to additional gestures (e.g. pinch) without an additional method.
2. Ability to forward from multiple elements to the same captured surface.

I'd argue that:
- No. 1 is unimportant - adding more methods is inexpensive.
- No. 2 does not solve any use case presented by Web developers. It might even be a footgun - consider partially-overlapping preview tiles.

It was only out of a desire to be flexible and accommodating of Youenn, that I offered to change the API this way. But since this is blocking consensus rather than helping it - because Mozilla objects to this new shape - let's go back to `captureWheel(element)`, which is good enough for all Web developers we've heard from.

> I'm also not convinced apps need to cherrypick behaviors in the first version.

I don't understand this part. Please clarify...?

> I'm not convinced about divs.

We have Web developer feedback that this is necessary, and their rationale is clear and reasonable; namely, they want to overlay the video with an element on which they draw emoji reactions and announcements, and these must not block scrolling. If you have reasons to doubt these Web developers, please share your thoughts. But let's concentrate on our role of **serving** Web developers.

> > Chrome does not plan to provide zoom through its UX. Does Firefox? Does Safari?
>
> Firefox might put zoom controls in the video element (next to its PiP button).

First, your alternative does not solve the problem - Web developers need the ability to overlay customized controls zoom-controls at their chosen position, alongside additional app-level controls, or overlaid on top of the video preview tile. Developers need to be able to do either of these, and not all be forced into the same design.

Second, you do not provide a real commitment by Firefox to your proposed alternative. You say Firefox "might" do it; this implies it also **might NOT** do it.

-- 
GitHub Notification of comment by eladalon1983
Please view or discuss this issue at https://github.com/w3c/mediacapture-screen-share-extensions/issues/13#issuecomment-2428972452 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Tuesday, 22 October 2024 11:01:30 UTC