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

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

From: Elad Alon via GitHub <sysbot+gh@w3.org>
Date: Wed, 26 Jan 2022 16:13:32 +0000
To: public-webrtc-logs@w3.org
Message-ID: <issue_comment.created-1022354841-1643213610-sysbot+gh@w3.org>
How common is it for specs to plug additional attributes directly onto HTMLElement? Checking the Chromium codebase just because that's the quickest way for me, it seems like it's [exceedingly rare](https://source.chromium.org/search?q=%22partial%20interface%20HTMLElement%22&ss=chromium). I expect that the Chromium implementation is a good approximation of what W3C specifications do, but if my hack at getting this information was misguided, please let me know.

As for extending HTMLElement, that's of course [quite common](https://source.chromium.org/search?q=%22:%20HTMLElement%22%20f:idl&ss=chromium) - but that's not what you're proposing. :-)

Btw, is it actually possible to expose a new field on all `HTMLElement`s without incurring **any** cost? I'm not sufficiently familiar with how this is implemented in Chrome, let alone in other browsers, but I'd expect a non-zero cost for this exposure even if the field is unset until it's first read. (Possibly as small as increasing a lookup table, which might only happen when the Nth new field is added. I am not sure. But probably it's not zero-cost...?)

> For instance, what happens in the case of calling produceCropTarget on a detached iframe for a HTMLElement which is not part of the detached iframe?

Could you please clarify how this edge-case would be problematic? The way I see it, if a given context can get a reference to the object in order to supply it as a parameter to `produceCropTarget()`, then that's all that matters.

> Calling twice produceCropTarget on the same element is expected to produce the same CropTarget, which might be surprising given it is a method.

I don't think that's surprising. We can also reduce the (IMHO already low) surprise factor by renaming to `getAsCropTarget` or something similar. But I think "produce" is good enough.

> using promises here is to accommodate a particular browser implementation

Politely disagree. It's done to afford all implementations the flexibility to implement efficiently and simply. If some implementations don't require this flexibility, I think it wouldn't harm them either - simply return the Promise pre-resolved.

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

Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 26 January 2022 16:13:33 UTC

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