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

> How common is it for specs to plug additional attributes directly onto HTMLElement?

I don't really know, it probably depends how much HTMLElement is actually used in APIs.
Infrastructure and implementations have prime support for that and some limited specs do that.

> is it actually possible to expose a new field on all `HTMLElement`s without incurring **any** cost?

I am not exactly sure which cost you are talking about. Is it that HTMLElement would get bigger in memory?
If so, implementations have the flexibility to either use a new member in HTMLElement, a separate map<element, region> or any other strategy.

> 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.

It would need to be tested but if frame is detached, chances are the promise will reject.
It does not make real sense to tie HTMLElement with an unrelated construct.
For instance requestFullScreen is at Element level, which begs the additional question whether CropTarget should be Element or HTMLElement. Element might make more sense.
I'll file a separate issue.

> It's done to afford all implementations the flexibility to implement efficiently and simply.

There is a tradeoff with promises, we should use them when/if they are needed, which does not seem to apply here.
Taking your previous example about potential race conditions, let's say we have A the capturee, B the capturer, C the entity doing the actual cropping, all living in 3 processes.
Your plan seem to be:
1. A->C->A to register a surface identifier from a HTMLElement identifier (asynchronous)
2. A creates a region from surface identifier
3. A->B to send the capture region
4. B->C to ask for cropping (asynchronsous)
5. C->B to say cropping is enabled.

Step 1 & 2 can be replaced by:
1. A creates a region from HTMLElement identifier (synchronous)
Then 5 will be replaced by
5a. C->A->C to identify surface identifier from HTMLELement identifier (B request identifies unambiguously A's process).
5b. C->B to say cropping is ongoing
In practice, C->A->C can be optimised to not be needed.





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


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Thursday, 27 January 2022 08:39:44 UTC