- From: Jan-Ivar Bruaroey via GitHub <sysbot+gh@w3.org>
- Date: Thu, 23 Sep 2021 13:41:10 +0000
- To: public-webrtc-logs@w3.org
> Here is a proposal: > > * Change getDisplayMedia parameter to take an optional DisplayMediaStreamConstraints dictionary What change? This is [literally already specified](https://w3c.github.io/mediacapture-screen-share/#dom-mediadevices). > * List explicitly the constraints supported by audio (restrictOwnAudio, suppressLocalAudioPlayback) and video (width, height, frameRate, maybe some others) in dedicated (boolean or dictionary) [It already does that](https://w3c.github.io/mediacapture-screen-share/#dfn-restrictownaudio), as [required by mediacapture-main](https://w3c.github.io/mediacapture-main/getusermedia.html#defining-a-new-constrainable-property). > * Add a new property to the video constraints dictionary specifically for the surface, which would take a typed enum instead of the not-tightly-typed ConstrainDOMString. > > This will make it clearer what makes sense in getDisplayMedia and what does not. I don't see how it does. This seems inconsistent with all other constraints for no reason. It also seems redundant, given we already have the [displaySurface](https://w3c.github.io/mediacapture-main/getusermedia.html#defining-a-new-constrainable-property) constraint. How would this new property interact with the existing constraint? What are the user benefits? > I do not believe this will cause any compatibility issue as this would match browser existing behavior more closely than what the spec is doing. Like it or not, all browsers have implemented the [Constrainable Pattern](https://w3c.github.io/mediacapture-main/#constrainable-interface) quite faithfully. There is some value in being consistent at this point, or at least require good reasons not to be, which I don't see here. > Over time, we could further clean up things: > > * remove the min/exact fields from getDisplayMedia WebIDL parameters. This will make getDisplayMedia to ignore them instead of rejecting The working group chose to reject these inputs instead of silently ignoring them, in order to give and early better feedback to callers, so this is on purpose. I don't see new evidence here to reopen that decision. > * remove the ideal syntax if we see it is not used in the field by migrating values from IDLConstrainBoolean to boolean for instance. Across the board, or just for this constraint? This seems like a minor implementer inconvenience in order to stay consistent with the pattern web developers recognize from getUserMedia. It would also be a web compat issue at this point. -- GitHub Notification of comment by jan-ivar Please view or discuss this issue at https://github.com/w3c/mediacapture-screen-share/issues/184#issuecomment-925827152 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Thursday, 23 September 2021 13:41:13 UTC