- From: youennf via GitHub <sysbot+gh@w3.org>
- Date: Fri, 24 Sep 2021 13:22:14 +0000
- To: public-webrtc-logs@w3.org
I also prefer an attribute over an explicit call for each track. This allows an application to set its default value easily (never focus for instance) while providing enough flexibility for web applications that want per-capture decisions. As of event task vs. micro task, there are preexisting examples. For instance, the fetch event is fired and some properties are read synchronously after the fetch event listeners, thus before the microtasks that would have been scheduled during the fetch event listeners. The main advantage I see is that it is a clear web developer contract: the boundary to call focus is the next await. I believe this approach also allows shiming since the read-focus callback would be executed after the already registered promise resolution callback. From a pure spec/developer point of view, it should be also easier to specify and implement: queue a task where the promise is resolved and a promise resolution callback to read the value and apply focus is registered. If we would like to leave the whole task to change the focus value, we might actually not want to read the value in the next task but at the point in the current task where the microtask queue gets emptied after the task steps are executed. I am not sure how doable that is right now in terms of spec editing. -- GitHub Notification of comment by youennf Please view or discuss this issue at https://github.com/w3c/mediacapture-screen-share/issues/190#issuecomment-926620679 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Friday, 24 September 2021 13:22:16 UTC