W3C home > Mailing lists > Public > public-webrtc-logs@w3.org > May 2022

Re: [mediacapture-region] Why expose produceCropTarget at MediaDevices level? (#11)

From: Elad Alon via GitHub <sysbot+gh@w3.org>
Date: Thu, 12 May 2022 07:44:21 +0000
To: public-webrtc-logs@w3.org
Message-ID: <issue_comment.created-1124643462-1652341460-sysbot+gh@w3.org>
> I am not sure what you are trying to point at. In any case, one scenario would be to use getElementById, something like: postMessage the ID from frame A to frame B. Then, when frame B wants to get info on the element (say its CSS class, its name...), frame B postMessages to frame A with the ID, frame A calls getElementById, gets the necessary bit of information and postMessages it back to frame B.

There's a big difference between these two scenarios:
1. A document D1 exposes an ID and receives back a message reading `{PLEASE: "invokeFunc4", param: id}`. At this point, D1 gets to **decide** whether it wants invokeFunc4() on the element.
2. A document D1 exposes an ID to D2. This ID might be further shared with D3. Various browser-level APIs may now be invoked on the corresponding element, initiated by either D2 or D3 or any other document. **Furthermore**, it's unclear if so much as an event would be fired for D1 when that happens. **Furthermore x2**, the set of browser-exposed APIs that can be invoked on that D2 and D3 could invoke on D1's element - it is unclear if that set of browser-exposed APIs could change.

So I ask:
* Is there a precedence for the second?
* If not, why are we so eager to set this precedence? Do we have a second API in mind? Who will benefit?

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

Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Thursday, 12 May 2022 07:44:22 UTC

This archive was generated by hypermail 2.4.0 : Saturday, 6 May 2023 21:19:57 UTC