- From: youennf via GitHub <sysbot+gh@w3.org>
- Date: Tue, 08 Feb 2022 09:55:33 +0000
- To: public-webrtc-logs@w3.org
Sorry in advance for this very long message but there are lots of different points.
> As Elad has pointed out, this approach is unlikely to gain consensus
@alvestrand, to be clear, I am not proposing we reject based on WebIDL.
I am proposing we define the property as a plain USVString with some special values.
> We can throw on `"monitor"` in prose regardless of API (if we decide to), so this seems like a separable discussion.
I was referring to the issue that we are exposing a value ('monitor') we actually do not want to expose to the open web (discussion has been about potentially using this value for transition).
> 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
I think you liked the idea to influence the prompt based on the fact that tabs would be site isolated.
As of orthogonal or not, how would you add a new 'hint' value if reusing displaySurface constraint?
Would you add two properties?
As of 'existing', current browsers do not support displaySurface in existing getDisplayMedia implementations.
> 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.
{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.
My understanding would be that, after the 'constraint' proposal, implementations would start to reject, which is a minor compatibility issue.
I would rather change the spec to match the implementations and explicitly list the constraints that are supported today.
And move away from this MUST-reject-on-exact model when adding new features.
> but consistency with getUserMedia and MST wins here in my book.
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.
We click on DisplayMediaStreamConstraints, great we stay in the same document and we learn about this structure.
We then want to understand what to put in the video object. We are now going to mediacapture-main spec which defines getUserMedia properties. We learn about 'advanced' (which ultimately cannot be used for getDisplayMedia).
We learn about MediaTrackConstraintSet for which most properties are useless to getDisplayMedia.
And we have to manually go back to mediacapture-screen-share to look at the getDisplayMedia properties and all the specific rules. This is not a great journey.
I'd prefer if we could make life easier than the current state, and describe in the spec what implementations are supporting (video width and height constraints and that is probably it).
Getting back to displaySurface as a constraint, it also makes it possible for web apps to do something like:
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?
With a USVString, there is no need to deal with this. I think a plain USVString is sufficient and simpler.
> if Youenn formulates an independent plan to move us generally away from constraints, I will likely be very interested.
There is no plan to move away from constraints, simply to not extend their use over what is implemented in browsers.
Plus a plan to describe more what is supported using WebIDL so that the specification is made clearer.
For instance, DisplayMediaStreamConstraints would be defined without referring to MediaTrackConstraints.
Instead we would list all the properties that are useful in the context of getDisplayMedia calls for audio and video explicitly within two WebIDL definitions (one for audio, one for video).
And we would add the 'picker' hint, either within DisplayMediaStreamConstraints or within the WebIDL dedicated to video.
--
GitHub Notification of comment by youennf
Please view or discuss this issue at https://github.com/w3c/mediacapture-screen-share/issues/184#issuecomment-1032419080 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 09:55:35 UTC