- From: jan-ivar via GitHub <sysbot+gh@w3.org>
- Date: Mon, 07 Aug 2017 17:18:57 +0000
- To: public-media-capture-logs@w3.org
@guidou You mean, what would happen with:
```js
await navigator.mediaDevices.getUserMedia({video: {width: 640, height: {max: 360}}});
```
? - Going back to intent and the two user groups I mentioned, the rule would be any use of keywords implies an intent to discover discrete modes, so: native <= ???x360 or `OverconstrainedError`.
Mixing bare values with min/max/exact/ideal, and ideal values purposely outside of a min-max range are edge-cases with little insight into user intent IMHO.
I think the question to ask is: What can developers not express with this?
Remember the current spec says *nothing* about this, and I'm only advocating for a SHOULD. I still prefer UAs in charge of this decision, so they can handle concurrent access well.
A new constraint would undermine that, and do nothing to solve the implementation discrepancy developers are facing today, because constraints don't have defaults.
`width`, `height`, `aspectRatio` and `frameRate` are the only non-orthogonal constrainable properties, in my experience.
> screen capture in Chrome tends to adjust to standard aspect ratios if constraints allow.
Screen capture is a different spec. We can always discuss screenshare-specific constraints there.
--
GitHub Notification of comment by jan-ivar
Please view or discuss this issue at https://github.com/w3c/mediacapture-main/issues/472#issuecomment-320725076 using your GitHub account
Received on Monday, 7 August 2017 17:19:02 UTC