Re: ConstrainDOMStringParameters would be good riddance

On 09/23/2014 07:47 PM, Jan-Ivar Bruaroey wrote:
> For numeric constraints, a single value represents an ideal target, 
> whereas a collection of values (in the form of a range) represents a 
> requirement.
>
ObQuibble: A range is not a collection of values.

> Logically, why doesn't the same hold true for strings and enums?
>
> In other words: For string and enum constraints, have a single value 
> represent an ideal target, and have a collection of values (in the 
> form of a sequence) represent a requirement?

>
> E.g.
>
>     { someEnumConstraint: "fourth" } // ideal
>     { someEnumConstraint: [ "third", "fourth", "fifth"] // required


How would we then represent "ideal: one of these, but I can live with 
something else"?

>
> Unlike numeric constraints, we don't need keywords like "min" and "max":
>
>     { someNumericConstraint: 4 } // ideal
>     { someNumericConstraint: { min: 3, max: 5 } } // required
>
> which means we don't need "ideal" and "exact" either, and can ax 
> ConstrainDOMStringParameters [1]
>
> Bonus: Enums no longer require per-type changes to the spec e.g. 
> ConstrainVideoFacingModeParameters

How come?
(btw, ConstrainVideoFacingModeParameters is gone - I think the pull 
request was yours)

>
> Simpler.

But losing the ability to express a particular semantic.

>
> .: Jan-Ivar :.
>
> [1] 
> http://w3c.github.io/mediacapture-main/getusermedia.html#idl-def-ConstrainDOMStringParameters
>
>

Received on Thursday, 25 September 2014 09:56:20 UTC