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

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

From: youennf via GitHub <sysbot+gh@w3.org>
Date: Mon, 28 Mar 2022 16:54:07 +0000
To: public-webrtc-logs@w3.org
Message-ID: <issue_comment.created-1080902581-1648486445-sysbot+gh@w3.org>
> Could you clarify what you mean here?

Which property of the mediaDevices instance are you using in the CropTarget production algorithm, except for its environment: none. You could easily change it to something like target = await MediaDevice.produceCropId(element).

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

I was not clear in my previous post: fine grained feature detection can be used to determine whether there is support for Element CropTarget or only HTMLElement CropTarget (say some browsers ship HTMLElement and add Element support as a follow-up).
If we use an Element/HTMLElement method, you just have to do !!Element.prototype.XYZ/HTMLElement.prototype.XYZ, this is super easy.
With mediaDevices.produceCropTarget, you need to call navigator.mediaDevices.produceCropTarget with a value that is an Element (and not an HTMLElement) to check whether it rejects and probably check the error is TypeError as well. This is not great.

> We prefer mediaDevices.produceCropId (vs Element.produceCropId()) because it's easier to feature-detect whether the API is available without needing an Element to detect the method presence. Hope that helps!

In terms of feature detection, an Element/HTMLElement method is better and easier, as shown above.
There is no need to create an element, you can just do Element.prototype.XYZ.

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

Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Monday, 28 March 2022 16:54:08 UTC

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