- From: Jan-Ivar Bruaroey via GitHub <sysbot+gh@w3.org>
- Date: Tue, 08 Feb 2022 00:03:53 +0000
- To: public-webrtc-logs@w3.org
> - The 'monitor' issue
We can throw on `"monitor"` in prose regardless of API (if we decide to), so this seems like a separable discussion.
> - 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...
These ideas go further wrt influencing user choice than what I'm comfortable with. They also seem orthogonal to looking at the _[existing](https://w3c.github.io/mediacapture-screen-share/#dom-mediatrackconstraintset-displaysurface)_ `displaySurface` constraint passed into _getDisplayMedia_ for a default category to show...
> - 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.
I don't see how. [displaySurface](https://www.w3.org/TR/mediacapture-streams/#dom-constraindomstring) uses DOMString, not enum, so `{video: {displaySurface: "foo"}}` _cannot_ 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.
I disagree. I'm no fan of constraints, but consistency with getUserMedia wins here in my book.
--
GitHub Notification of comment by jan-ivar
Please view or discuss this issue at https://github.com/w3c/mediacapture-screen-share/issues/184#issuecomment-1032066608 using your GitHub account
--
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Tuesday, 8 February 2022 00:03:55 UTC