> - 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-configReceived on Tuesday, 8 February 2022 00:03:55 UTC
This archive was generated by hypermail 2.4.0 : Saturday, 6 May 2023 21:19:56 UTC