- From: Jan-Ivar Bruaroey via GitHub <sysbot+gh@w3.org>
- Date: Thu, 10 Feb 2022 22:18:39 +0000
- To: public-webrtc-logs@w3.org
> I was referring to the issue that we are exposing a value ('monitor') we actually do not want to expose to the open web
Sites shouldn't be able to query `track.getSettings().displaySurface == "monitor"`?
> I think you liked the idea to influence the prompt based on the fact that tabs would be site isolated.
Yes, for _user agents_ to highlight some tabs over others (no spec changes needed for that), whereas here we're discussing an app signal on a default _category_ (it's up to user agents how to apply this signal to UX).
> As of orthogonal or not, how would you add a new 'hint' value if reusing displaySurface constraint?
> Would you add two properties?
That's hypothetical, as I'd prefer no more hints from apps.
> {video: { displaySurface: { exact: "monitor" }} does not reject right now in Chrome/Firefox AFAIK.
> It probably also applies to other constraints given to getDisplayMedia like cursor.
Seems irrelevant. `exact` is categorically a `TypeError` in [getDisplayMedia](https://w3c.github.io/mediacapture-screen-share/#dom-mediadevices-getdisplaymedia) (for all _implemented_ constraints due to WebIDL), so those are [implementation bugs](https://bugzil.la/1732122). E.g. `{video: { width: { exact: 640 }}` [fails with TypeError](https://jsfiddle.net/jib1/q75yb8pf/105/) in all browsers = don't use.
> My understanding would be that, after the 'constraint' proposal, implementations would start to reject, which is a minor compatibility issue.
Firefox would start rejecting as soon as we fix [bug 1732122](https://bugzil.la/1732122), so this is unrelated. It's also not really a compatibility issue since it doesn't do anything. By this standard, every new feature is a compatibility issue for people who guessed a future API name expecting it to not be there.
> Consistency with getUserMedia is not making it easy to understand getDisplayMedia.
> As an example, let's go to the definition of getDisplayMedia to find out how to call it.
Consistency = similarity in API shape and pattern (which users recognize from examples, MDN, or the [explainer.md](https://github.com/w3c/mediacapture-screen-share/blob/gh-pages/explainer.md))
Specs = blueprints for implementers, not docs for users. Improving their readability is an editorial issue, which [should not](https://www.w3.org/TR/html-design-principles/#priority-of-constituencies) influence API design.
> getDisplayMedia({video: { displaySurface: ["tab", "window"]}}).
> In getUserMedia, this is fine and unambiguous as we are using a distance and only one of the value can have a distance of 0.
> In getDisplayMedia case, it is not clear what UA should do there (prefer tab or prefer window).
> I would guess the spec would state that the first hint would be used?
I don't think we have to say anything. The app has declared a preference for tab or window. We don't specify UX.
> There is no plan to move away from constraints, simply to not extend their use over what is implemented in browsers.
Specs represent consensus, and right now, [displaySurface](https://w3c.github.io/mediacapture-screen-share/#dom-mediatrackconstraintset-displaysurface) is in the spec. If you feel it should be taken out, please file a separate issue, with new information worthy of reconsideration by the WG.
> Plus a plan to describe more what is supported using WebIDL so that the specification is made clearer.
That sounds editorial. I don't think it's reasonable to block API progress on editorial cleanup.
I'd like to get back to debating this on the merits of the proposed change.
--
GitHub Notification of comment by jan-ivar
Please view or discuss this issue at https://github.com/w3c/mediacapture-screen-share/issues/184#issuecomment-1035588529 using your GitHub account
--
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Thursday, 10 February 2022 22:18:41 UTC