Re: [mediacapture-region] What should the spec say about elements like HTMLAudioElement? (#51)

I am still puzzled by what we are discussing here. Can somebody summarise the various proposals?

A few thoughts:
* Chrome can certainly ship a partial implementation without any spec change. It often happens that implementations start with low hanging fruits and go to completion after some time. I thought this was Chrome team plan.
* Specs define the end goal. At some point, if the end goal is not reached or not reachable, we need to have a discussion to align the spec with what implementations have been/will be able to achieve. We are at the start of the cycle. The current end goal (Element) seems good to me.
* Learning from fullscreen API is a good idea. This was one reason I was in favor of supporting Element and not HTMLElement like initially proposed.
* Doing implementation prioritisation of an element type (HTMLVideoElement) over another (HTMLAudioElement) is a UA implementation decision, I do not see why we should discuss this here. The question we can ask here is whether we want to support HTMLAudioElement or not. So far, I have not seen any reason why we should remove support. It can have some very good uses (say reporting a bug about A/V synchronization and doing an A/V capture to help diagnose the issue). If it is very hard to implement correctly, we can always discuss this.

> 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.
I asked whether this is what Chrome team wanted/what this discussion was about and I am still not sure whether this is the case or not. Again, as I asked earlier:
Does Chrome team want to reduce the scope of the spec/proposal to div/iframe only?

> @youennf, you have previously agreed HTMLElement made sense, and [at your suggestion](, we even expanded to Element. You made this suggestion five months ago. The API as a whole has been debated for 1.5 years by now. I do not think this qualifies as "rushed".

Please reread the sentence where I used "rush".
It was referring to the API shape change we are trying to get consensus on.
Normally, we would present it at a WG interim meeting and then let editors finalise the PR.
There is a request to bypass WG interim meeting and land this PR asap so that Chrome can align its implementation with that proposal before shipping it. This qualifies as "rushed", especially since we now seem to be discussing changing the scope of the spec.

With regards to the overall discussion, here is a rough sketch:
* 1.5 year ago, Chrome team made a proposal. At the time, the end goal was to support HTMLElement.
* 0.5 year ago, I proposed to extend it to Element, so that SVG/MathML could be supported. This is current WG consensus and we continued API discussions based on that consensus.
* Chrome team is now (maybe, I am not sure) proposing to revert these decisions and scope it down to div and iframe only. This happens at the same time we are trying to change the API while Chrome team is trying to ship a first version of this API. This is not great timing.

GitHub Notification of comment by youennf
Please view or discuss this issue at using your GitHub account

Sent via github-notify-ml as configured in

Received on Monday, 30 May 2022 07:52:35 UTC