- From: Yoav Weiss via GitHub <sysbot+gh@w3.org>
- Date: Thu, 19 May 2022 10:03:48 +0000
- To: public-webrtc-logs@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. The current processing model seems indeed insufficient in describing what current implementations are doing (or planning to do). I sent https://github.com/w3c/mediacapture-region/pull/47 to clarify that part and make it (hopefully) more rigorous. > 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 [beg to differ](https://github.com/w3c/mediacapture-region/issues/11#issuecomment-1125790108) on that last part. > 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 don't believe that's the case. I provided spec clarifications at https://github.com/w3c/mediacapture-region/pull/47 in the hope that they'd help bridge our common understanding. > I can think of no reason why this needs to be async See [my comment above](https://github.com/w3c/mediacapture-region/issues/17#issuecomment-1129753450) > Asynchronous API's come at a cost to web developers, as they turn JavaScript into a pre-emptive language. Understood. At the same time, there's [general agreement](https://w3ctag.github.io/design-principles/#synchronous) that when locks or IPC calls are involved, async APIs are called for. I'd also like to stress out (again) that the TAG [did not find the burden significant](https://github.com/w3ctag/meetings/blob/gh-pages/2022/telcons/04-25-minutes.md#media-capture-region) in this particular case. -- GitHub Notification of comment by yoavweiss Please view or discuss this issue at https://github.com/w3c/mediacapture-region/issues/17#issuecomment-1131496050 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Thursday, 19 May 2022 10:03:50 UTC