- From: Jan-Ivar Bruaroey via GitHub <sysbot+gh@w3.org>
- Date: Thu, 23 Jan 2025 00:17:23 +0000
- To: public-webrtc-logs@w3.org
Who are these web developers and what library do they use? With more info we might be able help. The annotation use case starts out transparent and is therefore not faithless. So I'm not swayed by appeal to futility. The current API seems overly permissive. I'm also concerned we're committing a category error by baking the overlay problem into the initial design of this API, when it seems a fundamentally separate problem. If we ignore the overlay problem for a second, it seems obvious this API belongs on video element, which probably means that's the right place. 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. "Backwarding" might present additional challenges to that, but doesn't seem that different either. The overlay issue doesn't seem inherently unique to this api. 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? -- GitHub Notification of comment by jan-ivar Please view or discuss this issue at https://github.com/w3c/mediacapture-surface-control/issues/45#issuecomment-2608548934 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 00:17:24 UTC