- From: Elad Alon via GitHub <sysbot+gh@w3.org>
- Date: Mon, 30 May 2022 09:24:15 +0000
- To: public-webrtc-logs@w3.org
> I am still puzzled by what we are discussing here. Can somebody summarise the various proposals? I'll summarize again. Note that if you want to know what I am trying to discuss, it helps to focus on what I am saying, and not confuse my choice of topic with my [responses](https://github.com/w3c/mediacapture-region/issues/51#issuecomment-1139766931) to off-topic questions. See more on this below. The **general** topic is that minting can fail - but at [your request](https://github.com/w3c/mediacapture-region/issues/48#issuecomment-1136342837) this discussion was **branched**. There are [three categories](https://github.com/w3c/mediacapture-region/issues/48#issuecomment-1136330532) for these failures. The **current issue** discusses why I think minting should fail (synchronously) for `HTMLAudioElement`. The solution initially proposed was to allow the call to fail. Later, I reacted to your mention of reversion to iframe/div and mentioned it's a potential compromise. > Specs define the end goal. This refers specifically to the other topic - criterion 2 of [this message](https://github.com/w3c/mediacapture-region/issues/48#issuecomment-1136330532). You have asked me to branch the discussion off from there so as to keep these topics separate. So let's please observe your request - both of us. > Learning from fullscreen API is a good idea. Please read [this reply](https://github.com/w3c/mediacapture-region/issues/51#issuecomment-1139801961), which responded to the comparison with the fullscreen API. `HTMLAudioElement` means a different set of background pixels would be captured when comparing different implementations, and that's undesirable. > Doing implementation prioritisation of an element type ... I do not see why we should discuss this here. That's NOT what was being discussed. I had never discussed `HTMLVideoElement` except in response to Jan-Ivar's queries on the topic - and specifically to say "To answer @jan-ivar's new question - I think HTMLVideoElement makes a relatively sensible crop-target and I don't presently seek to pack it in the same bin with HTMLAudioElement." > > If this means scoping back down to div/iframe, as Youenn and I have both now suggested ([1][2]), then that works for me too. > > To be clear, I am not proposing that. > ... > Does Chrome team want to reduce the scope of the spec/proposal to div/iframe only? Thank you for the clarification. This reversion to div/iframe was NOT the original intention of this thread, but it DOES provide a shortcut out of this issue, and I'd love it if we took it. > Chrome team is now (maybe, I am not sure) proposing to revert these decisions and scope it down to div and iframe I believed you were floating the idea as a possible compromise; possibly temporary. > Normally, we would present it at a WG interim meeting and then let editors finalise the PR. All of the people who have expressed interest in this API during WG interim meetings are represented here. Continuing the discussion in 20min-per-month slots during interim meetings does not serve us. -- GitHub Notification of comment by eladalon1983 Please view or discuss this issue at https://github.com/w3c/mediacapture-region/issues/51#issuecomment-1140918999 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Monday, 30 May 2022 09:24:17 UTC