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

> * Better encapsulation, as CropTarget production is media/RTC-related, as is MediaDevices; Element is very general.

requestFullScreen API attached to Element directly is well encapsulated through partial interface.

> * In contexts where MediaDevices is missing (eg HTTP), this API would not be exposed, which is preferable.

SecureContext can be applied to methods as well as interfaces so this seems orthogonal.
With mixed context allowed, one could think of having a non secure context generate CropTarget for its SecureContext parent.

> * If we agree ([other thread]( that we need a Promise, then a method is more natural than an attribute.

Using promises is largely orthogonal in that case.
The question is more whether for a given element, you get the same CropTarget object (current spec behavior) or not.
With attributes, you get the same CropTarget calling get after get, this is an expected behaviour.
With methods, you would get different promises but the same fulfilled JS object.
Existing APIs that have this model tend to my knowledge to prefer attributes in that case (see FetchEvent, WHATWG Streams, WebAnimation as example).

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 Wednesday, 2 February 2022 14:17:56 UTC