W3C home > Mailing lists > Public > public-media-capture@w3.org > April 2014

Re: WebIDL-compatible syntax compromise

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>
Message-ID: <1447FA0C20ED5147A1AA0EF02890A64B1CFAD0EE@ESESSMB209.ericsson.se>
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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:26:25 UTC