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: Tue, 10 May 2022 18:35:52 +0000
To: public-webrtc-logs@w3.org
Message-ID: <issue_comment.created-1122736765-1652207751-sysbot+gh@w3.org>
> I think using them for this purpose makes perfect sense and is the kind of thing they were designed for.

I am not aware of any other API that accept the ID of an element from another document. Could you name one?

> Concrete absurd future hypothetical examples don't have any bearing on the actual existing element.id primitive. There are no security and privacy considerations for element.id; it's just a string.

(To simplify things, let's call those who argue here for the use of a general-purpose token The Generics, and those who argue for a cropping-only token The Singletons.)

First, I have used an absurd example precisely because the Generics have not yet provided an example of a future API that would benefit from a generic token. The burden of producing such an API is on them. 

Second, assuming the Generics can produce such a hypothetical API, they should then also explain why it's desirable to use a generic token. Assuming there are multiple APIs that are unblocked by that token, the application loses the ability to only unblock one when it posts such a token. How is that preferable? (Hard to answer without a concrete example of an API though... Which the Generics should produce.)

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

Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Tuesday, 10 May 2022 18:35:57 UTC

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