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

> I don't see a big advantage in exposing produceCropTarget() on a plethora of objects.

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

We discussed with @eladalon1983 some of the reasons why element was a better location during last editor's meeting.
At that time, I felt there was some consensus towards element.
Some reasons below:
- 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.
- MediaDevices is tied to its navigator hence to a specific Document. Elements can be transferred from one document to another. 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. There does not seem to be any reason to try going in those edge cases, that can get even weirder if using promises.
- The MediaDevices instance is not bringing anything to the creation of CropTarget, contrary to getUserMedia et al. A static MediaDevices.produceCropTarget would work equally well. Why trying to tie the algorithm to an object that is unused. In programming language, we usually try to remove unused parameters.
- Feature detection is more easy if tied to the element than with MediaDevices: `'cropTarget' in Element.prototype` in one case. With MediaDevices, you would need to actually call the produceCropTarget API to get the same result.
- There is no real difference between the two versions in terms of documentation/implementation, the separation of concerns is easy to do in both cases. Given we have partial interfaces, we would have Element+CropTarget.idl for instance.

GitHub Notification of comment by youennf
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 14:44:29 UTC