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

Re: [mediacapture-region] What makes CropTarget special to require an asynchronous creation? (#17)

From: Jan-Ivar Bruaroey via GitHub <sysbot+gh@w3.org>
Date: Wed, 18 May 2022 20:40:11 +0000
To: public-webrtc-logs@w3.org
Message-ID: <issue_comment.created-1130515718-1652906409-sysbot+gh@w3.org>
@yoavweiss I'm hearing vastly differing claims about what [produceCropTarget](https://w3c.github.io/mediacapture-region/#dom-mediadevices-producecroptarget) needs to do that aren't supported by the spec: The spec says: _"Calling produceCropTarget on an [Element](https://dom.spec.whatwg.org/#element) of a supported type associates that [Element](https://dom.spec.whatwg.org/#element) with a [CropTarget](https://w3c.github.io/mediacapture-region/#dom-croptarget). This [CropTarget](https://w3c.github.io/mediacapture-region/#dom-croptarget) may be used as input to [cropTo](https://w3c.github.io/mediacapture-region/#dom-browsercapturemediastreamtrack-cropto)."_

That's literally all it says: create an association between an interface that cannot be serialized with one that can.

Clicking on [CropTarget](https://w3c.github.io/mediacapture-region/#dom-croptarget) confirms this: _"CropTarget is an intentionally empty, opaque identifier that exposes nothing. Its sole purpose is to be handed to [cropTo](https://w3c.github.io/mediacapture-region/#dom-browsercapturemediastreamtrack-cropto) as input."_ — Nothing about cropping, preparing for cropping, IPC, render processes, or any failures. It's infallible and serializable, that's all.

There's no reason this needs to be asynchronous. We've had experienced Google folks suggest element.id be used instead — a proposal that fell for other reasons — but being synchronous never came up. I agree with @youennf we need to go back to the drawing board if Chrome has vastly different ideas for this than what they've proposed for standardization. 

I can think of no reason why this needs to be async, I could literally polyfill CropTarget by minting a MessagePort, and it would work in 90% of cases (same doc, same origin, same site, which has similar performance characteristics AFAIK, just not true cross-doc).

Asynchronous API's come at a cost to web developers, as they turn JavaScript into a pre-emptive language. I recommend [Why coroutines won’t work on the web](http://calculist.org/blog/2011/12/14/why-coroutines-wont-work-on-the-web/) as required reading here. I can also talk at length about async functions not having been great for WebRTC.

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

Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 18 May 2022 20:40:12 UTC

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