- From: Stefan Håkansson LK <stefan.lk.hakansson@ericsson.com>
- Date: Wed, 2 Apr 2014 14:13:34 +0000
- To: Dan Burnett <dburnett@voxeo.com>
- CC: "public-media-capture@w3.org" <public-media-capture@w3.org>
On 02/04/14 13:48, Dan Burnett wrote: > >>> 2. Non-required. >>> >>> Remaining members of the top-level dictionary whose names are NOT >>> in the 'require' list (the top-level 'frameRate' and >>> 'facingMode' entries in the example.) These do not correspond to >>> anything in the existing spec. >> >> This would basically be "hints"? I think that in the spec, the >> first example should only use non-required (as a simple start where >> the app hints > > Yes, except that they are actually constraints rather than hints. If > you'll notice in the description below, there would be a requirement > to satisfy as many as possible. This means that a UA must use/apply > the non-required constraints given when possible and as specified, > resulting in a clear determination for the UI of how it is to develop > its recommended device selection or configuration. It cannot > arbitrarily choose to ignore non-required constraints that would be > in the most-satisfiable set. As with Firefox it may be possible for > the user to override the recommended device selection as long as it > does not violate the required constraints, but that is an orthogonal > decision, since the UA is still required to follow the given > selection/application algorithm in determining its recommendation. You're right - they are constraints and not hints. > > Regarding examples, it will probably be useful to show increasing > complexity, i.e., - an example with only non-required constraints - > one with required and non-required constraints - one with required > and advanced constraints - one with all 3 kinds I agree.
Received on Wednesday, 2 April 2014 14:14:03 UTC