Re: [mediacapture-screen-share] Revisit: Let getDisplayMedia() influence the default type choice in the picker (#184)

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 using your GitHub account

Sent via github-notify-ml as configured in

Received on Friday, 4 February 2022 09:21:06 UTC