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

> Who are these web developers and what library do they use? With more info we might be able help.

During the interim meeting, I have pointed out Google Meet as one such example, and there are more.

The exact library is irrelevant; the important point is that the libraries are not modifiable by the app developer. Enough information was provided to discuss this from first principles.

> The annotation use case starts out transparent and is therefore not faithless. So I'm not swayed by appeal to futility.

If I understand you correctly, you mean that the gradual transition from zero occlusions to increasingly many occlusions leaves room for the UA to heuristically detect abuse. Did I understand you correctly? Why is restricting wheel-forwarding to occur from the video element required for that?

Note the priority of constituencies implies that if you can employ the same limitations either way, you should not put restrictions on Web developers.

> I haven't yet seen this library, but it seems reasonable that any interactive overlay that needs to selectively forward events to what's underneath needs to create synthetic events and some awareness of what's underneath.

This is both irrelevant and incorrect, given (1) that libraries are not necessarily modifiable by the Web developer, and that (2) existing libraries might not allow selective forwarding of events.

You assume that existing libraries routinely support selective forwarding of events. But why would this be the case? Why would existing libraries be designed to accommodate a future hypothetical limitation of some future API?

During the interim meeting, you took an action item to demonstrate how the use case could be tackled without support from the library. I look forward to your demonstration.

> The overlay issue doesn't seem inherently unique to this api.

If it is not unique, then you will have precedents to draw on in your demonstration of a solution, as per your action item from the interim meeting.

> Lastly, I think @guidou made the point in the meeting that the same limitations could be applied regardless of where the API lives. I think that works in the other direction too: I didn't get a clear answer how Chrome intercept input today, but if the limitations (e.g. hit zone no larger than the video element underneath the given div) are implementable regardless, why can't we move the API to the video element and solve the overlay the way it's done today?

Guido said that it does not matter (1) to the user agent (2) where the API is exposed (HTMLVideoElement or CaptureController), for the purpose of implementing additional limitations and heuristics. It **cannot** be inferred from his argument that it also does not matter to the (1) Web application where (2) wheel events are forwarded from.

You say “solve the overlay the way it's done today.” The current solution is to forward from an element other than the video element, such as a div. Since you propose to block that solution, it is incumbent on you to show how the use case could be tackled instead. During the interim two days ago, you took an action item to do as much. I am looking forward to that.


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


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

Received on Thursday, 23 January 2025 11:51:32 UTC