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

@yoavweiss I'm hearing vastly differing claims about what [produceCropTarget]( needs to do that aren't supported by the spec: The spec says: _"Calling produceCropTarget on an [Element]( of a supported type associates that [Element]( with a [CropTarget]( This [CropTarget]( may be used as input to [cropTo]("_

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

Clicking on [CropTarget]( confirms this: _"CropTarget is an intentionally empty, opaque identifier that exposes nothing. Its sole purpose is to be handed to [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 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]( 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 using your GitHub account

Sent via github-notify-ml as configured in

Received on Wednesday, 18 May 2022 20:40:12 UTC