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

> It is not on a plethora of objects, it is only either in MediaDevices prototype or HTMLElement prototype.

I think what @alvestrand was referring to, is that (i) this would now be exposed on many different sub-types of HTMLElement, as well (ii) exposed on multiple instances. If that's what he meant, I agree.

> MediaDevices is SecureContext, Element is not. It seems ok for a non secure document to be able to create a CropTarget. This might be handy in the future or in mixed contexts today. A context that does not need MediaDevices might still find it useful to create and transfer CropTargets.

That was an interesting case, but unclear to me how important it is to keep supporting non-secure contexts. Would they be able to `postMessage` the CropTarget, for instance? Would it be possible to trust the message in which they do so?

> Elements can be transferred from one document to another.

What's the mechanism for that?

> If we were to use MediaDevices, we would need to handle the case of creating CropTargets for elements which are not tied to the same document as the MediaDevices instances.

I don't think there has to be a connection between where the CropTarget-minting-API is exposed, to where the elements are, let alone where the CropTargets are.

> A static MediaDevices.produceCropTarget would work equally well.

Could you clarify what you mean here? I couldn't parse this in a manner consistent with the rest of the message. I mean, if there is a way to define produceCropTarget as exposed on the class MediaDevices, but not tied to any object, then that's fine by me...

> With MediaDevices, you would need to actually call the produceCropTarget API to get the same result.

Why would I need to **call** the function? Why can't I just check for its existence using `!!navigator.mediaDevices.produceCropId`?

GitHub Notification of comment by eladalon1983
Please view or discuss this issue at using your GitHub account

Sent via github-notify-ml as configured in

Received on Monday, 21 March 2022 16:20:24 UTC