- From: henbos via GitHub <sysbot+gh@w3.org>
- Date: Thu, 25 Oct 2018 09:16:16 +0000
- To: public-webrtc-logs@w3.org
Why does the UI have to reside inside of the web app to best influence the user to make the best choice? A good UI should help the user make the best choice, why is that UI inside the web app and not inside the browser's picker? The problems you're describing are not specific to a particular web app (any screen sharing web app would have the same pros/cons of a source); they are, however, largely specific to a _browser implementation_. Should your web app limit or encourage users to tab capture because Chrome does high fps screen share in that case, even though that distinction is irrelevant in Firefox? (I'm not saying this is necessarily the case, I'm making up an example.) My position is that it is up to the browser/implementation to help the user make the best choice, not the web app, unless the limitations are universal to any browser. You might end up filtering out an option that some other browser implementation is able to handle. With regards to audio I think audio source capabilities are platform specific and the web app should have little say in what audio the user picks, just like the web app has no say in which screen or which window the user picks. Audio being complementary part of screen sharing, we're making it optional to satisfy "audio:true" unlike "video:true". As long as the picker is clear to the user what they are sharing we should be good? -- GitHub Notification of comment by henbos Please view or discuss this issue at https://github.com/w3c/mediacapture-screen-share/issues/62#issuecomment-432976659 using your GitHub account
Received on Thursday, 25 October 2018 09:16:17 UTC