Re: [mediacapture-surface-control] Is gesture forwarding tied to capture controller or to MediaStreamTrack or to DOM objects? (#45)

> > Your own proposal of {overlay: element} amounts to forwarding from an arbitrary element. It aims to limit forwarding to elements overlaid on top of an actively playing video element, but it fails to do so, because the workaround is trivial:
>
> No that's incorrect. The browser would check that the coordinates of the wheel event it received (and the trusted duplicate) puts it over the video element (the "hit zone" I was referring to). I thought this was obvious but I should have included it, sorry.

I believe you have misread me here, but I don't think it's useful to continue this discussion right now. Let's shelve it.

> One improvement this WG has made over Chrome's existing demo is to put the user agent in charge of coordinates instead of leaving that to web developers.

I believe we at Google suggested this. It wasn't an improvement, it was a trade-off; it made one use-case simpler (local scrolling) at the cost of completely eliminating another use-case (remote scrolling). For us, this was a compromise, not an improvement.

> 7 of my 8 points were not primarily about mitigations, but about creating a superior API surface that naturally reflects the behavior I want

And [my responses](https://github.com/w3c/mediacapture-surface-control/issues/45#issuecomment-2624617759) laid out why I don't see this API surface as superior.

> It fixes usability flaws and surprises inherent in the existing API once we start moving things around a bit.

We have received feedback to the contrary from Web developers we are in touch with. They have found the proposal to expose the API over the video element to be a regression in clarity and usability.

> I suggest we focus on HTMLVideoElement first. We can extend it to HTMLCanvasElement later.

I oppose notion that this is a feature of the video element. This is a feature of the **capture-session** and the **forwarding-source-element**, regardless of the rendering engine for the preview tile. We have no reason to move from a general API shape that Web developers have expressed support for, and that already solves the problem for **any** rendering element (video/canvas/anything), to an API shape that is tied to **one** rendering element (video).

-- 
GitHub Notification of comment by eladalon1983
Please view or discuss this issue at https://github.com/w3c/mediacapture-surface-control/issues/45#issuecomment-2627509301 using your GitHub account


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

Received on Friday, 31 January 2025 14:39:01 UTC