- From: youennf via GitHub <sysbot+gh@w3.org>
- Date: Fri, 04 Feb 2022 09:21:04 +0000
- To: public-webrtc-logs@w3.org
Reusing displaysurface has some drawbacks:
- The 'monitor' issue
- A picker might like hints that reduce the sets of surfaces, or allows reordering them. Say: I prefer secured pages, or I prefer self tab, or I prefer the tab that is playing audio right now, or I prefer the non browser application that just opened me and happens to be code-signed by a related party...
- It creates some minor backward compatibility issues (either reusing directly the enum, or reusing the whole constraint structure) while I think a hint of this sort should never trigger reject.
- Style speaking (maybe this is just my taste), ```getDisplayMedia({ audio: true, video: true, prefer: 'window'})``` reads better than ```getDisplayMedia({ audio: true, video: { displaySurface: 'window'} })```. Clearer API is better for the web.
Hence why I would go with a new attribute extending DisplayMediaStreamConstraints as an open enum when supported by WebIDL and a USVString in the meantime.
The PR should anyway be small, whatever the option taken. I think this approach might be smaller in fact.
On the other hand, I do not really see what displaysurface gains us. Can you express the benefits of reusing displaysurface?
So far what I could think of is PR size or implementation size. I believe that both approaches will be roughly equally small.
> it will likely gain `monitor` at some point.
This is only a possibility at this point, who knows what future will be.
If that ever happens, we can very easily update the spec accordingly.
--
GitHub Notification of comment by youennf
Please view or discuss this issue at https://github.com/w3c/mediacapture-screen-share/issues/184#issuecomment-1029792963 using your GitHub account
--
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Friday, 4 February 2022 09:21:06 UTC