- From: Elad Alon via GitHub <sysbot+gh@w3.org>
- Date: Mon, 30 May 2022 09:23:51 +0000
- To: public-webrtc-logs@w3.org
> I am still puzzled by what we are discussing here. Can somebody summarise the various proposals? I believe I have summarized that multiple times now, but here's one more time. The discussion started in #17, which you branched off into #48, and which I was then [asked](https://github.com/w3c/mediacapture-region/issues/48#issuecomment-1135977959) - [twice](https://github.com/w3c/mediacapture-region/issues/48#issuecomment-1136324268) - to branch off here. I claimed these are related topic and that it would be better to discuss them all together, but you (@jan-ivar and @youennf) have insisted, so here we are. The general topic is that minting can fail. 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 for `HTMLAudioElement`. Previous commenters went into the topic of 0x0 pixels. I explained that this was NOT the issue. I explained what the issue really was in [this comment](https://github.com/w3c/mediacapture-region/issues/51#issuecomment-1139398297) and [this one](https://github.com/w3c/mediacapture-region/issues/51#issuecomment-1139801961). These messages also explained what the real issue is. > 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 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. > 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. > 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. -- GitHub Notification of comment by eladalon1983 Please view or discuss this issue at https://github.com/w3c/mediacapture-region/issues/51#issuecomment-1140918564 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:23:52 UTC